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The  development  work  summarized  in  this  final  report  was  carried 
out  by  Input  Output  Computer  Services,  Inc. ,  under  contract  to  the 
rj.S.  Department  of  Transportation,  Transportation  Systems  Center 
(OOT/TSC) .  The  research  was  sponsored  by  the  Pederal  Aviation 
Administration  (PAA)  as  part  of  their  Plight  Service  Station  (PSS) 
automation  program. 

The  system  described  in  this  report  is  intended  to  provide 
preflight  weather  briefings  to  the  aviation  community  via  computer'* 
generated  voice  output.  It  is  a  20-channel  Voice  Response  System 
(VRS)  which  uses  Adaptive  Differential  Pulse  Code  Modulation  (ADPCM) 
speech-compression  techniques  and  a  push-button  telephone  communi¬ 
cation  interface  for  a  real-time  pilot  self-briefing  system. 

The  work  reported  here  was  completed  under  the  direction  of  the 
TSC  program  manager,  Manuel  P.  Medeiros,  and  the  technical  monitors, 
John  J.  Sigona  and  Vito  P.  Maglione.  Carey  Weigel  of  the  PAA 
provided  overall  program  guidance. 
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1.  INTRODUCTION 


The  Direct  User  Access  ( DUA )  system  is  presently  being  developed 
as  a  component  of  the  FAA  Flight  Service  Station  Automation 
Program.  The  system  will  enable  pilots  to  interact  with  a  computer 
system  to  obtain  weather  briefings  and  file  flight  plans. 

Transactions  will  be  made  over  CRT  and  hardcopy  terminals  for 
graphical  and  textual  output,  and  over  Touch-Tone®  telephones  for 
spoken  briefings.  The  spoken  material  is  the  output  of  the 
20-channel  Voice  Response  System  (VRS)  developed  at  the 
Transportation  Systems  Center  (TSC)  in  Cambridge,  Massachusetts.  To 
date,  the  VRS  gives  (speaks)  three  weather  products  over  the 
telephone  with  stored  words:  Hourly  Surface  Observations  (SA) , 
Terminal  Forecasts  (FT) ,  and  Forecast  Winds  Aloft  (GF)  (Air 
Transport  Association  (ATA)  Grid  Winds  --  prepared  by  the  National 
Meteorological  Center  for  the  airlines) .  using  a  special  Touch-Tone 
protocol,  the  pilot  enters  the  three-character  location  identifier 
for  each  airport  or  weather  station  of  interest.  The  VRS  prompts 
the  pilot  to  indicate  which  weather  products  are  needed,  and,  if 
necessary,  to  enter  specific  altitudes  and  time  for  Winds  Aloft  data. 


1.1  VRS  FUNCTIONAL  OVERVIEW 

A  Oigital  Equipment  Corporation  (DEC)  PDP-11/34®  computer  issues 
the  prompts  and  receives  the  user's  requests,  sending  the  requests 
to  a  second  computer,  a  DEC  PDP-11/70®  which  has  access  to  the 
National  Weather  Service  files  in  Kansas  City,  Missouri.  The  11/70 
weather  processors  are  constantly  translating  incoming  weather 
products  into  sets  of  pointers  which  reference  the  VRS  dictionary  of 
recorded  words  and  phrases. 


When  the  11/70  weather  report  retrieval  program  receives  a 
request,  the  pointers  corresponding  to  the  required  weather  report 
are  located  and  sent  back  to  the  11/34.  The  specified  locations  in 
the  dictionary  file  are  read  and  the  data  sent  to  an  output 
subsystem  (the  Adaptive  Differential  Pulse  Code  Modulation  (ADPCM) 
decoder)  which  decodes  the  digital  data  and  converts  it  to  analog 
signals  (stored  records)  that  the  user  can  hear  over  the  telephone. 

1.1.1  PDP-11/34®  Functions 

The  VRS  computer  (i.e.,  the  POP  11/34)  performs  all  "terminal’’ 
functions.  These  functions  include:  accepting  input  from  the  user 
via  Touch-Tone®  phone,  transmitting  this  input  to  the  11/70  and 
providing  voice  output  of  information  sent  back  from  the  11/70.  The 
basic  software  flow  diagram  is  presented  in  Figure  1-1.  A  brief 
discussion  on  each  block  function  is  presented  as  follows  in  the 
sequence  that  the  computer  processes  the  information. 

The  user  input  enters  the  software  through  the  Touch-Tone 
driver.  The  driver  provides  device-dependent  function  handling, 
such  as  phone  answering  and  producing  ASCII  characters  from  the 
Touch-Tone  input.  The  driver  also  separates  the  input  from  all 
channels  into  separate  storage  areas. 

The  separate  storage  areas  are  then  examined  by  the  dialogue 
program.  This  module  collects  all  information  needed  by  the  11/70 
to  perform  data  retrieval.  The  information  collected  includes 
location  identifiers,  altitudes  and  weather  types. 

At  this  point,  the  program  prompts  (speaks  to)  the  user  to  input 
the  data  required.  The  program  has  a  collection  of  responses  that 
it  "speaks"  to  the  user.  These  responses  are  retrieved  and  spoken 
to  the  user  by  using  the  disk  driver,  the  disk  driver  completion 
routine,  the  ADPCM  driver,  and  the  ADPCM  completion  routine.  The 
disk  driver  reads  a  portion  of  the  message  to  be  spoken  and  executes 


the  disk  completion  routine.  The  disk  completion  routine  sends  the 
message  fragment  to  the  AOPCM  driver.  The  ADPCM  driver  speaks  the 
message  fragment  and  executes  the  AOPCM  completion  routine  which 
requests  another  disk  read  from  the  disk  driver.  This  process  of 
disk  driver,  to  disk  read  completion,  to  AOPCM  handler,  to  AOPCM 
completion,  continues  until  the  entire  message  is  spoken.  After 
completing  the  spoken  message  the  AOPCM  completion  routine  returns 
control  to  the  dialogue  program. 

The  information  collected  by  the  dialogue  program  is  formatted 
and  transmitted  to  the  PDP-11/70®  by  the  line  driver  output.  This 
driver  performs  the  functions  required  by  the  line  protocol.  This 
includes  insertion  of  all  protocol  characters,  and  data  retrans¬ 
missions  required  by  invalid  user  entries  or  line  interference. 

The  11/70  prepares  the  requested  data  for  transmission.  The 
data  arrives  at  the  line  driver  input  in  "message  units"  (defined  in 
Section  2. 4. 3. 4).  The  message  units  must  be  specifically  requested 
by  the  VRS  computer  before  they  are  sent.  A  request  for  the  next 
message  unit  is  sent  by  the  ADPCM  completion  routine  when  it  has 
completed  the  speaking  of  the  previous  one. 


1.1.2  PDP-11/70  Functions 


The  PDP-11/70  maintains  all  of  the  weather  data  which  are 
required  to  be  vocalized  by  the  VRS  computer.  The  PDP-11/70  will 
eventually  contain  the  software  required  to  process  eleven  different 
weather  report  types.  It  currently  contains  three  weather 
processors:  Surface  Observations  (SA) ,  Terminal  Forecasts  (FT) ,  and 
Forecast  Winds  Aloft.  The  processing  procedure  consists  of  three 
operations:  accessing  a  dynamic  data  base  of  weather  information  to 
recover  raw  weather  data;  translating  the  raw  weather  data  into  a 
format  which  is  recognized  by  the  VRS  11/34  computer;  and  storing 
the  translated  information  in  data  files  that  are  organized  to 
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process  is  one  of  mapping  ASCII*  weather  report  words  and  phrases 
into  their  corresponding  dictionary  file  addresses  of  the  locations 
where  the  actual  digitized  utterances  are  located. 

The  translation  requires  a  dictionary  (sort  for  indicating) 
where  each  word  and  phrase  are  located  in  the  vocabulary  file.  Two 
copies  of  the  dictionary  exist,  one  on  the  11/34  fixed  head  disk 
I  where  the  vocabulary  file  itself  resides,  and  the  other  on  the  11/70 

disk  where  it  is  accessed  by  the  weather  processors.  (When  the 
dictionary  is  updated  at  the  11/34,  it  is  sent  to  the  11/70  using  an 
off-line  utility,  SENDIC.) 

In  addition  to  translating  the  raw  data,  validity  checks  are 
made  and  unrecognized  words  or  formats  are  flagged  as  errors  for 
manual  editing.  The  method  of  handling  unrecognized  ASCII  com¬ 
binations  is  described  in  detail  in  Section  2. 4. 3. 5. 

*  The  PDP-11/70®  is  required  to  retrieve  weather  information  upon 

request  by  the  VRS  computer.  Three  modes  of  retrieval  (selected  by 
the  pilot)  have  been  defined  as  follows: 

1.  Local  -  Predefined  data  for  particular  locations  are 
presented  in  the  following  order,  if  available:  Area  Forecasts 
e.g.,  (WA,  ws,  ww,  WH)  Notices  to  Airmen-NOTAMS  (NO),  Density 
Altitude,  Surface  Observations  (SA)  ,  Pilot  Reports  (UA)  ,  Terminal 
Forecasts  (FT),  Forecast  Winds  Aloft,  and  weather  Synopsis  (SY) . 

2.  Selected  Weather  -  The  weather  reports:  SA,  FT,  UA,  NO,  SY, 
and  Winds  Aloft  (time,  altitude)  are  retrieved  for  each  location 
specified. 

t 


*  ‘American  Standard  Code  for  information  interchange  (ASCII) 


1-5 


3.  Prompt  -  The  user  is  asked  a  series  of  questions  requiring 
yes/no  answers  concerning  the  report  he  wants  for  the  specific 
locations.  The  prompt  mode  is  currently  the  mode  in  operation  for 
the  20-channel  system. 

The  PDP-11/70®  uses  a  Location  Index  Table  (LIT)  in  a  Universal 
Data  Pile  (DDF)  to  locate  the  disk  block  numbers  of  the  translated 
weather  reports  requested  by  the  user.  A  briefing  table  of  these 
block  numbers  is  constructed  and  used  for  reading  the  blocks 
containing  disk  pointers  that  indicate  the  stored  utterances  as 
transmitted  to  the  11/34.  The  disk  pointers  are  grouped  into 
logical  divisions  called  message  units  (see  Section  2. 4. 3. 4).  The 
11/34  begins  requesting  successive  message  units  when  it  is  ready  to 
speak,  and  the  11/70,  following  its  briefing  table,  reads  the  blocks 
into  a  buffer  and  sends  the  data  message  a  unit  one  at  a  time  to  the 
11/34.  The  11/70  software  configuration  is  shown  on  Figure  1-2. 

1.1.3  Global  Functions 

The  division  of  work  between  the  two  systems  implies  a  number  of 
functions  are  handled  by  both.  These  functions  are  system 
initialization,  error  handling,  and  communications. 

1. 1.3.1  Initialization  -  Initialization  of  the  VRS  involves  two 
distinct  operations,  program  startup  and  establishing  communica¬ 
tions.  The  exact  implementation  of  operations  may  be  different  in 
the  two  computers,  but  the  function  is  the  same. 

Program  startup  is  internal  to  the  two  systems.  The  proper 
programs  must  be  brought  into  core  memory  and  all  run  time  data 
bases,  such  as  I/O  buffers,  must  be  initialized.  Establishing 
communications  consists  of  the  11/34  logging  onto  the  11/70,  as  a 
human  would,  and  issuing  an  RSX-llD  monitor  command  to  load  and 
execute  the  retrieval  program  (RETREV) .  Continued  execution  of 


PDP-11/70*  VRS  Software 


RET REV  is  thereafter  verified  by  polling,  if  the  11/70  does  not 
respond  to  the  polls,  the  11/34  software  prints  an  error  message  and 
abor  ts . 

1.1. 3. 2.  Error  Handling  -  Errors  may  occur  in  the  actual  operation 
of  the  program.  A  reporting  function  must  exist  to  permit  tracing 
sources  of  error  to  improve  operation. 

Errors  fall  into  two  major  categories.  The  first  areas  are 
those  which  totally  incapacitate  the  VRS.  The  second  are  those 
which  permit  the  system  to  continue  operation,  but  in  a  degraded 
manner . 

The  first  category  includes  the  following  principal  areas: 

1)  Disablement  of  the  VRS  computer.  Hardware  failure  to 
prevent  the  VRS  computer  from  performing  its  VRS  functions.  This 
type  of  error  is  determined  using  device  status  registers,  and  bus 
timeouts  induced  by  accessing  totally  disabled  I/O  registers. 

2)  Line  Failure.  Both  the  11/70  and  the  VRS  computer  are 
prevented  from  communicating  as  a  result  of  serial  line  failure. 

The  total  failure  of  either  machine  will  appear  to  the  other  as  a 
line  failure.  Failures  are  determined  by  timeouts  on  the 
communication  line. 


The  second  category  of  errors  includes: 

1.  Raw  Weather  Data  Errors.  Format  problems  of  the  raw  weather 
data  due  to  spelling  errors,  or  other  format  problems  result  in 
these  errors  being  sent  to  the  Data  Editor  (see  Section  2. 4. 3. 5). 

2.  Garbled  Transmission.  Messages  sent  on  the  Communications 
line  will  occasionally  suffer  from  noise  and  line  outages.  This 
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includes  only  occasional  distortion  of  messages,  not  total  line 
failure  which  was  discussed  previously. 

3.  I/O  Errors.  On  occasion,  peripheral  devices  will  fail  on  an 
attempted  I/O  transfer.  This  type  of  error  is  rare  with  current 

>  technology  but  should  be  accounted  for  on  the  few  occasions  when 
they  do  occur. 

> 

Other  errors  such  as  software  failures  can  also  occur.  The 
above  list  can  be  expanded  as  implementation  proceeds,  but  is 
adequate  to  define  the  error  problem. 

1.1. 3. 3.  Communications  -  The  communications  task  provides  the  link 
between  the  systems.  It  must  format  data  in  a  manner  suitable  for 
serial  transmissions,  and  must  receive  the  data,  checking  it  for 
integrity  and  acknowledging  receipt. 

♦  ' 

*  The  line  is  bi-directional  and  the  messages  are  of  4  types.  The 

,  first  is  a  briefing  request.  This  message  is  transmitted  from  the 

*  11/34  to  the  11/70.  it  contains  data  used  by  the  11/70  to  access 
the  processed  weather  files.  The  11/70  responds  with  either  a 
positive  acknowledgment,  or  a  diagnostic  message  indicating  such 
things  as  improperly  spelled  data,  etc.  If  the  request  is  accepted, 
11/70  then  internally  prepares  the  data  corresponding  to  the 
retrieval  request.  Communications  integrity  is  checked  by  check-sum 
logic  via  the  11/34  and  the  Retrieval  (11/70)  program.  This  is 
explained  further  in  Chapter  2. 

1.2  PDP-11/34®  HARDWARE 

The  various  components  of  the  11/34  system  (see  Figure  1-3)  are 
as  follows: 
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VOTRAX  MC-I 
TOUCH-TONE 


FIGURE  1-3;  PDP-11/34  Hardware  Configuration 


CPU  -  POP - 11/3 4A  processor. 


e  Memory  -  64K  word  parity  core  memory  for  program  execution, 

e  TTY  -  System  master  console  (CDI  Teleterm  1030)  for  running 
the  VRS  system  and  for  software  development. 

e  Calendar  -  TCU-100  Hardware  clock  calendar  unit  used  by  the 
VRS  to  obtain  the  current  date  and  time  of  day. 

e  Clock  -  KW-ll/ti  real-time  clock  required  by  the  operating 
system  to  perform  timing  functions  such  as  timing  user 
response  time. 

e  Magtape  -  TU-10  Mag  tape  drive.  Required  for  regular 
back-up.  Used  to  copy  programs  and  vocabulary. 

e  Telephone  Company  (TELCO)  Switched  Lines  -  provides  access 
to  VRS  using  telephones. 

e  Bell  407C  Oata  Sets  -  Converts  the  Touch-Tones®  into 

signals  the  equipment  can  handle  incorporated  in  the  Bell. 

•  Touch-Tone  Mux  -  VOTRAX  MC-I  decodes  and  multiplexes  the 
Touch-Tone  input  from  the  twenty  407C  units. 

•  DLII-E  -  Asynchronous  interface  to  the  11/34  unibus  for  the 
VOTRAX  unit. 

•  20  Channel  AOPCM  Decoder  -  a  specially  designed  interface 
for  decoding  the  ADPCM  code  words  into  PCM  samples  and  then 
into  analog  signals. 


*taore  details  can  be  found  in  the  references.  See  (1)  for  oigital 
Equipment  Corporation  peripherals ,  Reference  2  for  special  purpose 
hardware.  See  also  (3)  and  (4)  for  the  Bell  Equipment. 


•  Audio  Vocabulary  Generator  and  A/0  -  audio  hardware  for 
inputting  the  vocabulary  (typically  a  tape  recorder  or 
microphone) . 

e  Fixed-Head  Disk  -  Digital- Development  Corporation 

(DDC-9112-D-8)  fixed-head  disk.  The  disk  is  used  for 
storage  of  VRS  software,  program  library,  operating  system, 
and  the  VRS  vocabulary.  Capacity  of  4  million  16-bit 
words,  1800  RPM,  17  ms  access  time. 

e  DL-11E  -  1200  bps  Asynchronous  Interface. 

e  Communications  Multiplexor  -  A  Computer  Transmission 
Corporation  Model  1315  communications  multiplexor  for 
communicating  with  the  PDP-11/70®  computer. 

1.3  POP -11/70  HARDWARE 

The  PDP-11/70  hardware  consists  of  768K  bytes  of  memory  with 
memory  management  and  a  dual  88  mega-byte  disk  storage  system.  The 
PDP-11/70  communicates  with  the  VRS  computer  via  a  single  channel  in 
the  multi-channel  DH-11  interface. 

The  PDP-11/70  system  is  controlled  by  RSX-11D/V6B,  which  is  an 
event  driven,  multiprogramming  operating  system  offering  up  to  250 
priority  levels  for  task  execution,  multiple  activity  monitoring, 
priority  interrupt  servicing,  task  scheduling,  dynamic  memory 
partitioning,  event  flags  for  task  notification  and  synchronization, 
support  of  multiuser  programs,  etc.,  as  well  as  on-line  software 
development,  concurrent  with  task  execution.  A  diagram  of  the  11/70 
configuration  is  shown  in  Figure  1-4. 


2.  VRS  SOFTWARE  DESIGN 


2 . 1  VRS  COMMUNICATIONS 

The  nature  and  formats  of  the  data  transmitted  between  the  two 
VRS  computers  are  described  in  this  section.  The  topic  of 
communications  line  protocol  and  the  associated  protocol  characters 
is  addressed  in  Appendix  B. 


2.1.1  Establishing  Communications 

When  the  11/34  operator  enters  the  RT-11  monitor  command,  'R 
VRS,'  to  begin  execution,  one  of  the  initialization  procedures  the 
11/34  VRS  software  performs  is  logging  onto  a  certain  11/70  disk 
area  to  initiate  execution  of  the  weather  report  retrieval  program, 
RETREV.  The  11/34  sends  the  characters  necessary  for  an  ordinary 
RSX-llD  log  on: 


HEL  {300,100] 

(current  password) 

RUN  RETREV, 

The  log-on  characters  are  echoed  back  to  the  11/34  which  types 
them  on  the  terminal  as  reassurance  to  the  operator  that  the  log-on 
is  happening  as  it  should.  (After  this,  no  further  transmissions  to 
the  11/70  are  echoed.)  If  the  log-on  and  all  other  initialization 
procedures  (discussed  in  subsequent  sections)  are  successfully 
completed,  a  message  to  that  effect  is  typed  on  the  terminal.  If 
the  message  does  not  appear,  communication  with  the  11/70  has  very 
likely  not  been  established  and  the  operator  would  take  off-line 
remedial  action.  When  communication  has  been  successfully 
established,  however,  the  11/34  undertakes  to  monitor  it  by  sending 


a  special  polling  message,  mtjll  BSC,  every  seven  seconds  to  RETREV, 
which  must  respond  with  '*1*  (ASCII  asterisk  one)  within  20  seconds 
or  the  11/34  assumes  that  either  RETREV,  the  11/70,  or  the 
communication  line  has  £ailed.  without  RETREV,  the  11/34  can  access 
no  weather  data,  so  it  informs  the  operator  of  the  trouble  and 
aborts  itself. 


The  11/34  computer  transmits  two  types  of  messages  to  the 
11/70:  briefing  compilation  requests  (type  1)  and  demand  response 
requests  (type  2) .  Type  1  messages  are  further  defined  into  two 
sub-types.  One  sub-type  is  briefing  request  message  #1  (BRM1) .  The 
other  sub-type  is  briefing  request  message  #2  (BRM2) . 

The  briefing  compilation  request  messages  consist  of  ASCII 
character  strings  (terminated  by  a  carriage-return  character)  which 
supply  the  parameters  that  the  PDP-11/70  employs  to  retrieve  weather 
data.  The  parametric  information  required  by  the  PDP-11/70  consists 
of  such  items  as  briefing  mode,  location  identifiers,  report  types, 
hours,  and  altitude. 

The  demand  response  requests  consist  of  ASCII  character  strings 
(terminated  by  a  carriage-return  character)  which  require  either  a 
transfer  of  verbalization  data  from  the  PDP-11/70  to  the  VRS 
computer  or  informs  the  PDP-11/70  of  some  special  condition  of  the 
briefing  (shut-down,  hangup,  etc.) 

2. 1.2.1  Type  1  VRS  Computer  to  PDP-11/70  Transmission  -  There  are 
two  sub-types  of  the  type  1  transmission.  They  are  identified  as 
briefing  request  message  #1  (BRMl)  and  briefing  request  message  #2 
(BRM2) . 


r 


BRMl  is  used  to  inform  the  PDP-11/70®  of  three  briefing 
parameters:  channel,  briefing  mode,  and  location  identifiers. 

BRM2  is  used  to  inform  the  POP-11/70  of  four  briefing 
parameters:  channel,  report  types-,  time  (hours  from  current  time)  , 
and  altitude. 

An  entire  series  of  BRM2  transmissions  may  logically  be  issued 
for  a  single  BRMl  transmission  and  thus  effectively  cause  a  briefing 
session  to  be  a  series  of  sub-briefings  for  the  locations  indicated 
in  the  BRMl  transmission.  This  permits  the  user  to  be  actively 
involved  in  the  progressions  of  the  briefing  in  order  that  he  may 
make  subsequent  requests  based  upon  previous  weather  information. 

The  general  form  of  BRMl  is  shown  below.  The  two  fields  are 
generalized  as  Fl  and  F2. 

BRMl:  XF1-F2(CKS]  [CR] 

X:  Channel  Number:  ASCII  0-19 

PI:  Mode:  LM,  SM,  PM,  (for  local,  selected, 

or  prompt) 

F2:  Location  identifier  string 

CKS:  A  three-character  check-sum  consisting  of  a 

two-character  encoded  sum  of  all  transmitted 
characters  followed  by  a  character  total  of 
the  number  of  transmitted  characters. 


i 


t 

I 


Example:  X  Fl  F2 

8  PM-BOS/ALB/BDF  [CKS] 
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Field 

Entry 

Meaning 

FI 

Mode 

Prompt  Mode 

F2 

Locations 

Boston,  Albany 

Buffalo 

This  briefing  compilation  request  informs  the  PDP-11/70®  that 
the  user  has  requested  a  prompt  mode  briefing  for  Boston,  Albany, 
and  Buffalo.  The  VRS  computer  has  assigned  the  user  to  channel  8. 

The  general  form  of  BRM2  is  shown  below.  The  three  fields  are 
generalized  as  Pi,  F2,  and  F3 . 


BRM2: 

XF1-F2-F3  [CKS]  f CR] 

X: 

Channel  Number:  ASCII  0- 

19 

PI: 

Report  types 

F2 : 

Times  (hours  from  current 

time) 

F3 : 

Altitude  (in  feet  or  feet 

x  100) 

Example: 

X  FI  F2  F3 

4  SA/FD-12 -9700 [CKS] [CR] 

Field 

Entry 

Meaning 

FI 

Report  types 

SA's, 

FD's  (winds) 

F2 

Hours 

Winds 

for  12  hours 

in  advance 

F3 

Altitude 

Winds 

for  9700 

feet 
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This  briefing  compilation  request  informs  the  PDP-11/70®  that 
the  user  on  channel  4  has  requested  Hourly  Surface  Observations  and 
Forecast  winds  Aloft  for  the  locations  previously  entered  during  a 
BRMl  transmission.  The  winds  aloft  are  desired  for  9700  feet  and 
the  twelve-hour  forecast  is  requested. 

2. 1.2. 2  Type  2  VRS  Computer  to  PDP-11/70  Transmission  -  This 
transmission  type  is  the  method  by  which  the  VRS  computer  demands  an 
immediate  response  from  the  PDP-11/70.  The  transmission  is  in 
ASCII -mode.  There  are  three  fields  of  information  supplied,  with  an 
optional  fourth  field.  The  request  is  terminated  with  a 
carriage-return  character. 

The  general  form  of  a  type  2  transmission  is  shown  below.  The 
left  and  right  brackets  are  used  to  indicate  that  the  enclosed 
information  is  optional.  The  brackets  are  for  illustrative 
purposes,  and  are  not  transmitted. 

Type  2:  &XY[ [CKS]  [CR] 

Field  1:  &,  type  2  identifier 

Field  2:  X,  X  *  channel  number  ASCII  0-19 

Field  3:  Y,  Y  *  command  code  (A,  B,  C,  D) 

Field  4:  nin2N3N4'  message  unit  number 

The  command  codes  (Field  3)  represent  the  different  types  of 
responses  the  VRS  computer  expects. 

When  Field  3  is  an  A,  the  VRS  computer  is  informing  the 
PDP-11/70  that  the  briefing  session  is  completed  and  that  the 
channel  is  released  (i.e.  telephone  hang-up  or  disconnect). 


When  Field  3  is  a  B,  the  VRS  computer  is  requesting  that  the 
PDP-11/70®  supply  the  message  unit  data  and,  in  addition,  echo  the 
message  unit  number  (See  Section  2. 1.3. 2). 


When  Field  3  is  a  C,  the  VRS  computer  is  requesting  that  the 
PDP-11/70  send  the  message  unit  number  and  message  unit  data  of  the 
first  message  unit  of  the  next  report  type  of  the  briefing.  When 
Field  3  is  a  D,  the  VRS  computer  is  requesting  that  the  PDP-11/70 
send  the  message  unit  number  and  message  unit  data  for  the  first 
message  unit  of  the  report  that  contains  the  requested  message  unit 
(i.e.,  backup  to  the  beginning  of  the  current  spoken  report). 


Field  3 
A 
B 
C 
D 


Field  4  Required 
Yes  *  0 
Yes  - 
Yes  * 

Yes  =» 


2.1.3  PDP-11/70  to  PPP-11/34®  Transmissions 

The  PDP-11/70  answers  the  two  types  of  VRS  computer  trans¬ 
missions  with  two  types  of  responses.  A  type  1  response  is  an 
ASCII-mode  transmission  which  is  used  for  two  purposes:  to  indicate 
a  completely  acceptable  briefing  request;  and  to  "echo*  an  invalid 
command  string  representing  a  request  for  a  briefing.  A  type  2 
response  is  a  transparent-mode  transmission  which  responds  to  a 
demand  response  request.  This  is  the  transmission  which  delivers 
the  voice  pointers  and  size  data  which  the  VRS  computer  uses  to 
vocalize  the  weather  information. 


2. 1.3.1  Type  1  PDP-11/70  to  PDP-11/34  Transmission  -  The  type  1 
response  to  the  VRS  computer  is  an  ASCII-mode  message  which  is  a 
response  to  a  briefing  request.  The  ASCII-mode  message  is  used  for 
diagnostics:  one  of  which  is  a  statement  that  the  PDP-11/70  can 
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r* - 

comply  with  the  transmitted  request;  the  second  of  which  is  an  echo 
of  a  briefing  request  with  @'s  substituted  for  the  subfields  which 
are  acceptable.  Type  1  responses  are  terminated  with  carriage- 
returns. 

Type  1:  Acceptable 
X  [CR]  [CKS] 

This  transmission  consists  of  the  channel  number  (ASCII  0-19) . 
Type  1:  BRMl  echo 

X0 -BOP/0/IAE  [CR]  [CKS] 

This  is  a  diagnostic  response  to  a  request  on  channel  X  (ASCII 
0-19)  in  which  the  briefing  mode  was  acceptable  and  the  second 
location  identifier  was  acceptable.  Locations  BOP  and  IAE  were  not 
located  in  the  system  data  base. 

I 

Type  Is  BRM2  echo 

XFS/@-@-7  [CR]  [CKS] 

* 

This  is  a  diagnostic  response  to  a  request  on  channel  X  (ASCII 
0-19) ,  in  which  an  invalid  report-type  was  requested  (FS) ,  a  valid 
report-type  was  requested,  the  time  field  is  valid  and  the  altitude 
field  is  invalid. 

2. 1.3. 2  Type  2  PDP-11/70®  to  PDP-11/34®  Transmission  -  A  type  2 
\  transmission  to  the  VRS  computer  is  used  to  honor  a  demand  response 
request.  This  transmission  is  in  binary  transparent-mode  and 
consists  of  the  command  echo,  the  channel,  the  message  unit  number, 
and  the  message  unit  data  (if  applicable).  The  general  form  of  the 
transmission  (characters  in  brackets  are  optionally  transmitted)  is: 
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Type  2:  CE  l,1»2l*3l,4I*lA2 


where,  C  is  an  eight  bit  echo  of  the  demand; 

E  is  an  eight  bit 'channel  number; 

to  ^  is  a  32  bit  message  unit  number; 

^1  t0  An  ace  the  8’bit  bytes  of  the  message 
unit. 

With  reference  to  Section  2. 1.2. 2,  request  codes  B,  C ,  and  0 
require  the  message  unit  data  and  request  code  A  requires  a  special 
message  unit  number  zero,  which  is  a  confirmatory  signal  to  the 
POP-11/34®  that  the  PDP-11/70®  is  closing  all  activity  on  the 
specified  channel.  If  any  command  other  than  A  contains  a  response 
of  message  unit  zero,  a  message  unit  has  been  requested  which  is 
beyond  the  range  of  the  briefing. 


2.2  PD9-11/34  RESIDENT  SOFTWARE 

Section  1.1  provides  a  brief  introduction  to  the  functions 
provided  by  the  11/34  VRS  computer.  The  software  to  perform  these 
functions  is  discussed  here. 


The  RT-11  Version  3  Extended  Memory  monitor  is  used  as  the 
operating  system  for  the  VRS  computer.  The  various  components  of 
the  VRS  system  are  depicted  in  Figure  2-1.  The  function  of  each  of 
the  components  of  the  system  will  be  given  later.  Here  we  will 
discuss  the  different  priority  levels  of  the  components. 


t 

The  driver  components  operate  at  three  priority  levels.  Read  or 
write  I/O  commands  are  initiated  at  priority  zero,  the  lowest 


% 

» 
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11/70 


FIGURE  2-1:  VRS  System  Components 


processor  priority.  Data  characters  sent  or  received  by  the  drivers 
are  processed  at  priorities  four  or  five.  This  guarantees  instant 
response  to  data  interrupts.  The  disk  and  ADPCM  completion  routines 
operate  at  interrupt  priority  five.  The  receive  completion  routine 
operates  at  priority  four.  The  dialogue  program  operates  at 
priority  zero.  The  trap  handler,  the  component  synchronizer, 
operates  at  priority  seven,  the  highest  process  level.  The  line 
timeout  component/ which  monitors  the  activity  of  all  lesser 
components,  operates  at  priority  six. 

The  11/34  software  is  examined  under  the  following  section 
headings: 


e  Data  Bases 
e  Device  Orivers 
•  Dialogue  Program 
e  Completion  Routines 
e  Line  Time-Out 

e  Trap  Handler 


2.2.1  Data  Bases 


The  VRS  computer  maintains  four  data  bases. 


These  data  bases  are: 


e  Queues 
e  Buffers 
e  Dser  Status  Blocks 

e  Dialogue  Protocol  Index. 

I 


2.2. 1.1  Queues  -  Queues  are  linked  lists  consisting  of  a  queue 
header  and  a  chain  of  any  number  of  queue  elements.  The  queue 
header  is  a  two- word  field  that  determines  the  limits  of  the  chain 
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of  queue  elements.  The  first  word  points  to  the  first  queue  element 
and  the  second  word  points  to  the  last  queue  element.  If  there  are 
no  queue  elements  in  the  queue,  both  words  are  set  to  a  zero  value. 
Figure  2-2  shows  three  examples  of  queued  lists. 

Ml  queue  elements  linked  to  a  specific  queue  header  are  members 
of  that  particular  queue.  Each  queue  element  of  a  particular  queue 
is  a  consecutive  block  of  memory  whose  first  word  is  a  link  pointer 
to  the  next  element  of  the  queue.  If  the  queue  element  is  the  last 
element  of  the  queue,  the  link  pointer  value  is  zero.  The  values 
contained  in  the  remainder  of  the  consecutive  block  of  memory  depend 
on  the  queue  function. 

Figure  2-3  shows  an  I/O  queue  element  used  by  the  RT-11  system 
to  queue  I/O  orders.  The  link  word's  function  is  described  in  the 
previous  paragraph.  Word  1  contains  the  VRS  channel  number  and  the 
I/O  function  code.  Word  2  is  used  by  the  RT-11  operating  system. 
Word  3  is  the  block  address  for  random  access  devices.  Word  4 
contains  the  input  or  output  buffer  address.  Word  5  is  the  word 
count  that  determines  the  number  of  words  to  transfer,  word  6  is 
the  completion  code  which  determines  the  action  to  take  upon 
initiating  or  completing  the  I/O. 

The  VRS  contains  three  different  types  of  queued  elements:  the 
I/O  queue  elements,  disk  read  queue  elements  and  11/70  receive  queue 
elements.  The  I/O  queue  elements  weri  explained  in  the  previous 
paragraph.  The  disk  read  queue  elements  are  elements  whose 
consecutive  block  of  memory  contains  a  link  field,  followed  by  a 
five  word  I/O  parameter  list,  followed  by  a  1024  word  input/output 
buffer.  The  element  is  used  to  read  disk  voice  data  and  write  the 
data  to  the  ADPCM  driver.  The  receive  queue  elements  contain  a  link 
field  followed  by  a  64-word  data  buffer  used  to  send  or  receive  data 
to  or  from  the  11/70. 
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FIGURE  2- 3:  I/O  Queue  Element 


2. 2. 1.2  Buffers  -  The  VRS  software  uses  three  types  of  buffers. 

The  first  is  a  40- word  Touch-Tone®  input  buffer  permanently  assigned 
to  each  of  the  VRS  channels.  All  translated  Touch-Tone  input  is 
placed  into  this  buffer.  The  buffer  is  also  used  to  transmit 
briefing  requests  to  the  11/70.  The  second  is  a  1024-  word  buffer 
used  for  reading  disk  voice  data  and  speaking  the  data  using  the 
ADPCM  driver.  The  third  is  a  64-word  buffer  used  to  receive  input 
from  the  11/70  and  to  echo  Touch-Tone  input. 


2.2. 1.3  user  Status  Block  -  A  user  status  block  (USB)  is  assigned 
to  each  VRS  channel.  The  USB  is  a  separate  data  base  enabling 
asynchronous  operation  of  all  VRS  channels.  Figure  2-4  defines  the 
fields  of  the  USB.  The  following  describes  each  field  of  the  USB: 

•  Bytes  0,1  contain  the  beginning  address  of  the  permanently 
assigned  40  word  buffer. 

•  Bytes  2,3  contain  the  byte  location  within  the  40  word 
buffer  that  will  receive  the  next  translated  Touch-Tone 
input  character. 

•  Bytes  4,5  contain  the  byte  location  within  the  40  word 
buffer  of  the  start  of  the  last  input  field,  i.e., 
beginning  of  last  location  identifier  or  weather  report 
type,  etc. 

•  Byte  6  contains  the  first  character  of  a  Touch-Tone  input 
keystroke  pair. 

•  Byte  7  contains  the  current  position  within  the  dialogue. 

•  Bytes  10,11  contain  the  identifier  of  the  last  component  of 
the  system  that  serviced  the  line. 
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Bytes  12,13  are  the  completion  mask,  which  is  a  unique  bit 
for  each  VRS  channel.  The  bit  is  used  to  distinguish  which 
particular  VRS  channel  is  signalling  a  significant  event. 

Byte  14  contains  an  event-  vector  to  distinguish  the 
particular  event  being  signalled  by  the  completion  mask. 

Byte  15  contains  the  flag  bits  that  signal  the  functions  to 
take  place  during  this  particular  step  of  the  dialogue 
protocol. 

Bytes  16,17  contain  flag  bits  that  govern  the  functions  to 
take  place  during  two  or  more  steps  of  the  dialogue 
protocol. 

Bytes  20,21  contain  the  flag  bits  that  signal  what  report 
types  are  available. 

Bytes  22,23  are  the  pointer  to  the  sequence  of  field  pairs 
that  define  the  message  to  be  spoken. 

Bytes  24,25  contain  the  number  of  words  in  the  last  block 
of  the  voice  data  for  the  current  utterance  being  spoken. 

Bytes  26,27  are  the  number  of  disk  blocks  that  contain  the 
utterance  being  spoken. 

Bytes  30,31  contain  the  disk  block  number  of  the  utterance 
being  spoken. 

Bytes  32,33  are  the  queue  header  and  bytes  34,  35  are  the 
tail  pointer  of  the  read  queue  elements  queued  for  the 
ADPCM  handler. 

Bytes  36,37  are  the  address  of  the  instruction  where 
processing  will  resume  when  the  current  message  is  spoken. 


o  Bytes  40/41  contain  the  header  and  bytes  42,  43  contain  the 
tail  for  the  read  queue  elements  currently  queued  to  the 
disk  handler. 

o  Bytes  44  through  46  contain  the  return  address  pointers  to 
the  subroutines  that  are -to  be  returned  to  after  a  briefing 
request  completes. 

o  Bytes  50/51  define  the  current  briefing  mode:  selected/ 
local,  or  prompt. 

o  Bytes  52  through  55  contain  the  ASCII  number  of  the  last 
briefing  message  unit  received  from  the  11/70. 

o  Bytes  56  through  61  are  the  queue  header  of  all  receive 
queue  elements  of  message  units  received  from  the  11/70. 

o  Bytes  62  through  65  contain  the  ASCII  number  of  the  last 
briefing  message  unit  requested  from  the  11/70. 

o  Bytes  66,67  contain  the  queue  header  and  bytes  70,71  are 
the  tail  of  the  message  units  queued  to  be  spoken. 

o  Bytes  72  through  75  contain  the  ASCII  number  of  the  message 
unit  that  is  currently  being  spoken. 

o  Byte  76  is  the  channel  binary  code. 

o  Byte  77  is  the  channel  ASCII  code. 


2. 2. 1.4  Dialogue  Protocol  Index  -  A  dialogue  protocol  index  is  used 
to  prompt  the  user  through  one  step  of  the  protocol.  The  dialogue 
protocol  index  indicates  what  functions  are  to  take  place 
immediately  before,  during,  and  immediately  after  a  single  step  of 


the  usee  dialogue.  Figure  2-5  shows  the  fields  of  a  dialogue 
protocol  index. 

e  Bytes  0,1  contain  the  flag  bits  placed  into  the  user  status 
block  at  the  beginning  of" this  step  of  the  user  dialogue. 

e  Bytes  2,3  are  the  address  of  the  special  function 

subroutine  to  be  performed  before  speaking  the  prompt 
message. 

•  Byte  4  contains  the  number  of  seconds  to  wait  before 
speaking  the  prompt  message. 

•  Byte  5  contains  the  number  of  seconds  to  wait  before 
echoing  the  user  response. 

•  Bytes  6,7  define  a  message  link  to  enable  all  dialogue 
protocol  indices  that  speak  the  same  prompt  message  to  use 
the  same  stored  canned  message. 

•  Bytes  10,11  contain  the  address  of  the  stored  canned 
message  unit. 

•  Bytes  12,13  define  the  address  of  the  special  function 
subroutine  to  be  executed  before  performing  the  syntax 
analysis  check. 

•  Bytes  14,15  define  the  syntax  analysis  check  mask  to  verify 
the  user  input. 

•  Bytes  20,21  define  the  address  of  the  special  function 
subroutine  to  be  performed  before  beginning  the  next 
dialogue  protocol  index. 

•  Byte  22  defines  the  next  dialogue  protocol  index  to  execute 
if  the  user  makes  a  normal  or  yes  response. 
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Byte  Number 
Octal 


0 

2 


3  4 


6 

10 

12 

14 

16 


20 


23  22 


FLAG  BITS 


SPECIAL  FUNCTION 
BEFORE  SPEAKING 


ECHO  PROMPT 

WAIT  WAIT 


MESSAGE  LINK 


PROMPT  MESSAGE 


SPECIAL  FUNCTION 
BEFORE  SYNTAX  ANALYSIS 


SYNTAX  CHECK  MASK 


SPECIAL  FUNCTION 
BEFORE  ECHOING  RESPONSE 


SPECIAL  FUNCTION 
BEFORE  NEXT  DIALOGUE 


NO 

or 

YES 

or 

ABNORMAL 

BRANCH 

NORMAL 

BRANCH 

NOTE:  All  fields  are  optional  except  the  prompt 

message  and  the  yes/no  branch  vector  fields. 


FIGURE  2-5:  Dialogue  Protocol  Index 


Byte  23  defines  the  next  dialogue  protocol  index  to  execute  if 
the  user  responds  with  an  abnormal  or  no  response. 


2.2.2  Device  Drivers 


The  VRS  software  performs  all  of  its  I/O  using  the  programmed 
requests  provided  by  RT-11.  Hence,  all  reads  and  writes  of 
information  must  obey  the  conventions  of  the  operating  system. 
Reference  9,  the  RT-11  Advanced  Programmers  Guide  describes  these 
programmed  requests  and  shows  how  specialized  handlers  must  work 
within  the  constraints  of  RT-11.  The  RT-11  Advanced  Programmers 
Guide  is  recommended  reading  for  full  comprehension  of  the 
specialized  handlers. 


2. 2. 2.1  Touch-Tone®  Driver  (MCX)  -  The  Touch-Tone  driver  is  RT-11 
compatible  with  the  exception  of  its  servicing  of  read  requests. 

The  driver  services  the  input  Touch-Tone  keystrokes  by  decoding  and 
inserting  the  decode  character  into  the  fixed  40-word  VRS  Touch-Tone 
input  buffer  for  the  designated  channel.  It  decodes  a  pair  of  input 
keystrokes  if  alphanumeric  input  is  expected,  or  a  single  keystroke 
if  numeric  input  is  indicated.  The  Touch-Tone  driver  services  write 
requests  to  enable  or  disable  a  VRS  channel.  The  driver  notifies 
the  dialogue  program  when  any  significant  event  occurs  on  a  VRS 
channel  by  setting  the  user  status  block  completion  mask  bit  into  a 
fixed  memory  location.  Significant  events  reported  are:  telephone 
ringing,  disconnect,  input  complete,  invalid  input,  etc. 


2. 2. 2. 2  DL-11  Line  Interface  Driver  -  The  DL-11  interface  is 

controlled  entirely  by  line-in  and  line-out  software. 


2. 2. 2.3  Fixed-Head  Disk  Driver  (RFX)  -  The  fixed-head  disk  driver 
is  an  RT-11  driver.  Exact  details  of  what  this  implies  are 
described  in  Reference  6,  Chapters  2,  4,  and  5. 
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2. 2. 2. 4  ADPCM  Driver  (ADX)  -  When  VRS  wants  to  speak  a  message  to 
the  user,  it  calls  the  ADPCM  driver,  which  initiates  speech  on  the 
proper  channel.  The  ADPCM  hardware  does  not  require  processor 
intervention  while  speaking  a  message  because  it  is  a  direct  memory 
access  device.  When  the  ADPCM  hardware  runs  out  of  speech  data,  it 
calls  the  ADPCM  interrupt  routine_which  checks  for  errors.  Then  it 
starts  the  next  speech  message  to  the  channel.  If  there  are  no 
speech  messages,  it  turns  off  the  ADPCM  hardware  on  that  channel. 
Finally,  the  ADPCM  handler  initiates  the  ADPCM  completion  routine 
with  the  channel  number. 

2.2.3  Dialogue  Program 

The  dialogue  program,  operating  at  priority  zero  (the  lowest 
machine  priority)  constantly  checks  the  status  of  a  significant 
event  completion  indicator  located  in  a  fixed  memory  word.  The 
Touch-Tone®  driver  indicates  a  significant  event  by  setting  the  user 
status  block  completion  mask  bit  for  the  affected  channel.  The 
Touch-Tone  driver  also  sets  the  particular  significant  event  code. 
Figure  2-6  is  a  schematic  flow  of  the  priority  zero  VRS  software. 
Table  1  presents  the  functions  performed  and  their  effects. 

The  dialogue  program  significant  event  recognition  routine 
sequentially  checks  each  of  the  VRS  channels.  This  sequential  check 
guarantees  consecutive  servicing  of  all  VRS  channels.  Using  the 
completion  event  code  set  by  the  Touch-Tone  driver,  the  significant 
event  recognition  routine  vectors  to  the  proper  servicing  routine. 


* 


The  significant  event  service  routines  are: 


e  The  telephone  ringing  service  routine 
which  activates  the  11/70  retrieval 
program  if  no  other  VRS  channels  are 
active  and  initializes  the  user  status 
block. 

•  The  telephone  disconnect  service  routine 
which  notifies  the  11/70  retrieval  program 
that  the  briefing  is  complete  for  the  given 
channel  and  if  no  other  VRS  channels  are 
active,  deactivates  the  11/70  retrieval 
program. 

•  The  yes/no  and  normal  completion  service 
routines  set  their  unique  status  indicator  into 
the  status  field  of  the  user  status  block. 

•  The  repeat  last  prompt  service  routine 
enables  the  repetition  of  the  last  message 
prompt. 

•  The  skip  or  repeat  service  routine  disables 
the  current  operation  of  the  briefing  com¬ 
ponent  and  requests  from  the  11/70  either 
the  previous  message  unit  for  a  repeat,  or 
a  skip  to  the  next  report. 


All  of  the  service  routines,  with  the  exception  of  the  skip  or 
repeat  service  routines,  interface  to  the  dialogue  protocol  index 
routine.  The  dialogue  protocol  index  routine  directs  and  conducts 
the  operation  on  a  VRS  channel.  Using  the  dialogue  pointer 
contained  in  the  USB,  the  dialogue  protocol  index  routine  executes 
one  step  of  the  protocol.  The  routine  initiates  the  speaking  of  a 
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message  prompt  to  the  user.  The  routine  also  directs  the 
Touch-Tone®  driver  to  decode  the  user  responses  as  alphanumeric  or 
numeric  input.  Finally,  the  routine  performs  a  syntax  analysis 
check  on  the  user  input,  echoing  a  correct  response  if  the  dialogue 
protocol  index  indicates  the  user  input  is  to  be  echoed.  It 
executes  the  appropriate  special  service  subroutines. 

The  special  service  subroutines  perform  services  that  are  unique 
for  a  particular  dialogue  protocol  index.  Examples  of  some  of  the 
services  performed  are: 

o  Formatting  the  Touch-Tone  input  to  separate 
logical  fields. 

o  Changing  briefing  modes. 

o  Clearing  the  Touch-Tone  input  buffer. 

o  Recognition  of  last  location  identifier. 

o  Skipping  to  another  dialogue  protocol  index. 

o  Formatting  a  specific  weather  report  type. 

o  Sending  briefing  requests  to  the  11/70. 

The  dialogue  protocol  index  routine,  using  its  special  service 
subroutines,  requests  the  user  input  location  identifiers.  The 
complete  set  of  location  identifiers  is  formatted  and  sent  to  the 
11/70  retrieval  program.  The  retrieval  program  validates  each 
location  identifier.  If  all  location  identifiers  are  valid,  the 
11/70  retrieval  program  sends  back  an  acknowledgment  to  the  11/34 
VRS  software.  If  any  location  identifiers  are  invalid,  the 
retrieval  program  sends  back  a  diagnostic  message  which  identifies 
which  location  identifiers  were  valid  and  which  location  identifiers 
were  invalid.  A  special  service  subroutine  within  11/34  VRS 
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requests  the  user  correct  the  invalid  location  identifiers  by 
cancelling  them  or  re-inputting  another  location  identifier.  The 
correct  location  identifiers  are  retransmitted  to  the  11/70. 

Dependent  upon  the  particular  briefing  mode,  the  dialogue  • 

protocol  index  routine  may  ask  the  user  for  additional  input.  For  a 
local  mode  briefing,  no  other  information  is  requested  and  the 
dialogue  protocol  index  routine  enters  briefing  mode.  For  a  prompt 
briefing,  the  user  is  asked  a  series  of  questions  requiring  a  yes  or 
no  response.  For  each  yes  response,  a  weather  report  type  request 
is  sent  to  the  11/70  retrieval  program  and  the  dialogue  protocol 
index  routine  enters  briefing  mode.  For  a  select  mode  briefing,  the 
user  is  asked  to  input  the  weather  report  types.  The  input  weather 
report  types  are  sent  to  the  ll/70/  and  the  dialogue  protocol  index 
routine  enters  briefing  mode. 

The  preceding  material  has  explained  the  operation  of  the  lowest 
priority  routines  of  the  VRS  software.  The  operation  services  in  a 
serial  fashion  each  of  the  VRS  channels  that  indicates  a  significant 
event.  For  a  given  VRS  channel  to  perform  the  functions  detailed  , 

above,  there  are  a  number  of  significant  events.  Each  time  a 
message  is  spoken  to  the  user,  requesting  a  user  response,  a 
significant  event  is  required  to  cycle  the  user  to  the  next  step  of 
the  dialogue  protocol.  In  general,  the  VRS  completes  instructions 
for  a  single  VRS  channel  before  it  cycles  back  to  check  for  a 
significant  event  on  another  VRS  channel. 

2.2.4  Completion  Routines 

The  completion  routines  operate  at  an  interrupt  level  priority 
zero.  They  are  capable  of  interrupting  the  processing  of  the  zero  ? 

priority  software.  One  of  the  completion  routines  is  the  receive 
completion  routine  which  receives  messages  from  the  11/70.  If  the  * 

received  message  is  an  acknowledgment  from  the  11/70  of  a  briefing 
request,  the  receive  completion  routine  transfers  control  to  the 
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dialogue  protocol  index  routine  try  setting  a  completion  code  and  the 
completion  mask  in  the  same  manner  as  the  Touch-Tone®  driver. 

Figure  2-7  demonstrates  the  logical  flow  of  the  completion  routines. 

If  the  received  message  from  the  11/70  is  a  briefing  message 
unit,  the  receive  completion  routine  interfaces  with  the  speech 
initiator.  The  speech  initiator  called  by  the  receive  completion 
routine  or  by  the  dialogue  protocol  index  routine,  initiates  the 
verbal  output  by  requesting  a  read  of  the  appropriate  voice  data 
from  the  disk  driver.  The  disk  driver  activates  the  disk  completion 
routine  when  the  disk  read  completes. 

The  disk  completion  routine  requests  the  ADPCM  driver  speak  the 
voice  data.  After  speaking  the  voice  data,  the  ADPCM  driver 
executes  the  ADPCM  completion  routine.  The  ADPCM  completion  routine 
determines  if  the  entire  message  prompt  or  the  entire  briefing  has 
been  spoken.  If  it  determines  that  the  entire  speech  has  not  been 
spoken,  it  requests  another  disk  read  of  the  next  portion  of  the 
prompt  message  or  briefing.  If  all  of  the  current  briefing 
verbalization  has  been  spoken  and  it  is  not  the  end  of  the  briefing, 
the  ADPCM  completion  routine  requests  another  briefing  message  unit 
from  the  li/70. 

To  effect  continuous  speech,  all  read  requests  to  the  disk 
handler  are  buffered  ahead  so  that  the  ADPCM  driver  always  has  the 
next  portion  of  the  verbal  message  to  be  spoken.  The  ADPCM  driver 
automatically  starts  speaking  the  next  portion  upon  completion  of 
the  last,  when  the  entire  message  or  briefing  is  complete,  the 
ADPCM  completion  routine  cycles  back  to  the  dialogue  protocol  index 
by  setting  a  completion  code  and  the  completion  mask,  the  same  as 
the  Touch-Tone  driver  and  the  receive  completion  routine. 


2-27 


11/70 


I 


FIGURE  2-7  :  Completion  Routines 


2.2.5  Line  Timeout  Routine 


The  line  timeout  routine  performs  two  functions.  First,  it 
resends  unanswered  requests  to  the  11/70.  If  a  communication  error 
has  occurred — either  the  11/70  or  the  11/34  has  dropped  a 
message — then  line  timeout  will  retransmit  the  request  three  times, 
at  five-second  intervals.  If  the  data  are  not  received,  the  user  is 
disconnected. 

The  second  function  performed  by  line  timeout  is  checking  for 
pilot  Touch-Tone®  input.  If  no  reply  is  made  to  a  prompt  by  the 
11/34  after  fifteen  minutes,  then  a  disconnect  message,  "Your 
briefing  has  been  terminated  due  to  excessive  time,"  is  spoken  and 
the  line  is  disconnected. 


2.2.6  Trap  Handler 

The  trap  handler  operates  at  priority  seven,  the  highest  machine 
priority.  The  trap  handler  synchronizes  operations  among  the 
various  components  of  the  operating  system.  An  example  is  the 
adding  or  taking  an  element  away  from  a  queue  header.  Without  the 
synchronizing  feature  of  the  trap  handler,  a  component  of  the  system 
operating  at  a  certain  priority  could  be  taking  the  element  from  a 
given  queue,  be  interrupted  by  a  high  priority  routine  that  takes  an 
element  from  the  same  queue.  Without  a  synchronizing  method,  both 
components  may  well  receive  the  same  queue  element.  The  trap 
handler  routines  are: 

•  Adding  an  element  to  a  queue  (queue) 

•  Taking  an  element  from  a  queue  (dequeue) 

•  Modifying  the  status  field  of  the  user  status  block 

•  Resolving  an  absolute  user  status  block  address 


•  Removing  the  significant  event  status  bits  from  the  fixed 
memory  location. 


2.3  STATISTICS  PACKAGE  OVERVIEW 

In  order  to  measure  the  use  of  the  Voice  Response  System,  the 
software  on  the  PDP-11/34®  maintains  a  data  base  describing  each 
user's  actions.  A  record  is  kept  of  when  each  user  called,  what 
reports  were  requested,  which  location  identifiers  were  requested, 
if  any  special  commands  were  requested,  and  when  the  caller  hung 
up.  The  data  base  (VRDATA.DAT)  is  created  by  the  VRS  software  each 
day  and  is  a  chronological  file  indicating  all  "significant  events" 
for  each  call. 


2.3.1  Statistics  File  Initialization 


Each  time  the  PDP-11/34  software  is  started,  the  statistics  file 
(VRDATA.DAT)  is  initialized.  There  are  three  types  of 
initialization: 

1.  Start  with  no  statistics  file  -  under  the  condition 
that  the  file  VRDATA.DAT  does  not  exist,  the  VRS 
software  creates  a  file  of  1,000  blocks  in  length. 

The  file  is  zeroed  such  that  all  records  are  made 
blank. 

2.  Start  with  a  complete  file  -  under  the  condition 
that  the  system  was  taken  down  by  the  operator  with 

an  "EXIT"  command,  the  file  is  defined  to  be  complete. 

On  normal  EXIT  of  the  system,  pointers  to  the  last 
data  written  in  the  file  are  written.  When  the 
system  is  started  again,  these  pointers  are  used  to 
define  where  to  write  subsequent  data. 
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3.  Start  up  after  a  system  failure  -  under  the  conditions 
of  a  crash  of  the  system,  the  pointers  to  the  last 
data  written  in  the  file  are  not  updated.  On  initial¬ 
ization,  the  software  reads  the  file  to  the  end  and 
.  begins  writing  data  at  the  end  of  the  previous  data. 

.  < 

2.3.2  Statistics  Pile  Structure 

2. 3. 2.1  Overall  File  Structure  -  The  statistics  file  is  circular  in 
nature  and  is  1,000  blocks  long.  The  first  block  of  the  file  is 
reserved  as  a  pointer  block.  All  other  blocks  in  the  file  contain 
data.  The  pointer  block  depicted  in  Figure  2-8  shows  the  format  of 
the  pointer  records. 

As  mentioned  above,  VRDATA.DAT  is  a  circular  file,  that  is, 
after  the  last  physical  block  of  the  file  is  written,  the  software 
will  begin  writing  over  the  existing  oldest  data  in  the  file.  The 
.  file  has  been  constructed  sufficiently  large  to  accommodate  24 

hours'  worth  of  data  for  twenty  users  without  wrapping.  If  the  file 
should  wrap,  however,  the  pointers  to  the  file  are  modified  during 
initialization  to  reflect  the  new  start  and  end  of  file. 

2. 3. 2. 2  Record  Structure  -  The  record  definition  appears  in 
Figure  2-9.  All  values  appearing  in  the  text  are  octal.  The  first 
element  is  the  record  header  containing  a  value  of  -16.  The  field 
data  generated  by  each  trace  element  is  16  bytes  long.  The  second 
element  is  the  length  of  the  variable  data  record.  It  is  equal  to 
the  number  of  bytes  stored  as  data.  The  third  element  (fJS.CHN)  is 
the  channel  being  recorded.  The  low  byte  contains  the  binary 
value.  The  upper  byte  contains  its  ASCII  equivalent  (used  in 

v  communications  with  the  Retrieval  Program) .  The  fourth  element 
f  (fJS.STA)  contains  the  line  status  and  as  such  defines  the  reason  for 

|  the  trace.  The  low  byte  of  fJS.STA  can  take  on  the  following  values: 
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Word 


4 


0 

Date 
12 

Date 

DATE 

LOW  TIME 

HIGH  TIME  - 

BLOCK  START  = 

OFFSET  START  '== 
BLOCK  END  = 
OFFSET  END  E 


2 

Low  Time 
14 

Low  Time 


•  High  Time 
16 

High  Time 


6 

Block  Start 
20 

Block  End 


10 

Offset  Start 
22 

Offset  End 


16  BIT  INTEGER  CONTAINING  TODAY'S  DATE 

(See  Section  2.4.10  of  RT-11  Advanced  Programmer's 
Guide)  . 

16  BIT  INTEGER  CONTAINING  LOW  16-BITS  of  the  number 
of  seconds  since  midnight. 

THE  HIGH  order  number  of  seconds  since  midnight. 

> 

STARTING  BLOCK  of  data  in  the  file.  (3  until 
file  wraps) . 

How  far  into  the  block  the  data  begins  (usually  0) 
Last  block  of  data  in  the  field. 

How  far  in  the  block  the  data  are  written. 


FIGURE  2-8:  Record  Pointer  Block 
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FIGURE  2-9:  Record  Definition 


NAME 

VALUE 

EXPLANATION 

RING 

40 

Channel  is  ringing 

DISCON 

41 

Hang  up  in  progress 

STOP 

42 

Briefing  stopped  by  user 

GO 

43 

Briefing  restarted  by  user 

REPEAT 

45 

Briefing  repeated  by  user 

SKIP 

46 

Report  skipped  by  user 

ST.INV 

47 

Invalid  entry  by  user 

CANCEL 

50 

Cancel  last  entry 

ST.SNO 

11 

LOC-ID's  Transmitted 

ST.  RNA 

13 

Receive  from  Washington 

not  accounted  for 

The  fifth  element  is  the  current  value  of  the  protocol,  US. 

KEY.  The  high  order  byte  of  this  record  defines  what  the  user  is 
currently  doing.  The  low  order  byte  contains  a  value  only  if  a 
control  keystroke  was  the  last  character  entered  by  the  user. 

The  sixth  element,  US.FLG,  contains  temporary  protocol  bits 
describing  what  the  user’s  current  status  is  in  the  high  byte,  and  a 
vector  to  the  routine  last  executed  at  base  level  in  the  program  in 
the  low  byte.  Following  is  a  list  of  low  byte  values  of  US.FLG. 


NAME 

VALUE 

EXPLANATION 

INVALK 

0 

User  took  abnormal  (NO) 

response 

NORMAL 

1 

User  took  normal  (YES) 

response 

RECYC 

2 

user  typed  "Begin  Over" 

SKIP 

3 

User  requested  a  skip  function 

INVALK 

4 

User  did  not  use  valid 

Touch-Tone®  entry 

RING 

5 

Telephone  is  ringing 

01 SCON 

6 

Telephone  has  been  disconnected 

YES 

7 

user  answered  "Yes" 

NO 

10 

User  answered  "No" 

RETURN 

11 

Return  from  high  level  routine 
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BRIEFER 

12 

Leave  briefing  mode 

REPEAT 

13 

Repeat  question  or  report 

CANCEL 

14 

Cancel  last  entry 

GO 

15 

Proceed  with  briefing 

STOP 

16 

Stop  briefing 

The  high  order  byte  contains  the  following  status  infor¬ 
mation: 


Position 

Name 

ON 

OFF 

Bit  8 

FL.ENP 

User  may  not 

User  may  enter 

enter  data 

data 

Bit  9 

FL.NUM 

User  must  enter 

May  enter  alpha¬ 

numer ic 

numeric 

Bit  10 

FL. DAP 

Cyclic  call 

Non-cyclic  call 

Bit  11 

FL.ECH 

Response  to  be 

No  echo  of  res¬ 

echoed 

ponse 

Bit  12 

FL.PHE 

Phonetic  echo 

Non-phonetic  echo 

Bit  13 

FL.DIS 

User  may  not 

User  may  enter 

enter  data 

data 

Bit  14 

FL.TKD 

Speech  is 

Speech  in  pro¬ 

finished 

gress 

Bit  15 

FL.ECD 

Echo  is 

Echo  in  progress 

finished 

The  seventh  element  contains  more  status  information 

PER)  ,  and 

is  depicted 

below: 

Position 

Name 

ON 

OFF 

Bit  0 

FL.TRA 

Software  maint¬ 

enance 

Bit  1 

FL.YER 

Yes  response 

No  response 

Bit  2 

FL. OBL 

Receive  double 

Receive  single 

buffered  buffered 

Hang  up  in  No  hang  up  in 

progress  progress 


Bit  3 


FL.TRN 


Bit 

4 

FL.BGN 

Begin  Protocol 

Continue  Protocol 

Bit 

5 

FL.LST 

Last  LOC  ID 

Last  LOC  ID  not 

entered 

entered 

Bit 

6 

FL.BRF 

Briefing  Mode 

Non -Briefing  Mode 

Bit 

7 

FL. BRD 

Briefing 

Briefing  in  prog¬ 

finished 

ress 

Bit 

8 

FL.FIR  ' 

First  pass 

No  first  pass 

thru  protocol 

Bit 

9 

FL.INT 

Stop  speech 

Continue  speaking 

Bit 

10 

FL.SKP 

Skip  ahead  in 

Not  skipping  data 

prog . 

Bit 

11 

FL. LOC 

Entering  LOC- 

Not  entering  LOC- 

ID'S 

ID's 

Bit 

12 

FL .COR 

Correcting 

Not  correcting  LOC 

LOC -ID's 

ID'S 

Bit 

13 

FL.SPC 

Special  Key¬ 

Last  character  not 

stroke  entered 

special 

Bit 

14 

FL.5PK 

Speaking  at 

Not  speaking  at 

base  level 

base  level 

Bit 

15 

FL  .  RTS 

Skip  or  repeat 

Neither  skip  or 

repeat 

The  eighth  element  contains  the  low  order  time  since  mid¬ 
night  in  seconds.  The  ninth  element  contains  the  high  order  time 
since  midnight. 


The  tenth  and  final  element  is  the  data  buffer  for  the  user. 


retrieval  program.  It  is  variable  in  length  and  its  length  is 
defined  as  the  second  element  in  the  record.  This  element  will 
contain  the  location  identifiers  requested  by  the  user. 


Bit 

4 

FL.BGN 

Begin  Protocol 

Continue  Protocol 

Bit 

5 

FL.LST 

Last  LOC  ID 

Last  LOC  ID  not 

entered 

entered 

Bit 

6 

FL.BRF 

Briefing  Mode 

Mon -Briefing  Mode 

Bit 

7 

FL.BRD 

Briefing 

Briefing  in  prog¬ 

finished 

ress 

Bit 

8 

FL. FIR 

First  pass 
thru  protocol 

Mo  first  pass 

Bit 

9 

FL.IMT 

Stop  speech 

Continue  speaking 

Bit 

10 

FL.SKP 

Skip  ahead  in 

Mot  skipping  data 

prog . 

Bit 

11 

FL.LOC 

Entering  LOC- 

Mot  entering  LOC- 

ID's 

ID's 

Bit 

12 

FL.COR 

Correcting 

Mot  correcting  LOC 

LOC -ID's 

ID'S 

Bit 

13 

FL.SPC 

Special  Key¬ 

Last  character  not 

stroke  entered 

special 

Bit 

14 

FL.3PK 

Speaking  at 

Mot  speaking  at 

base  level 

base  level 

Bit 

15 

FL  .  RTS 

Skip  or  repeat 

Meither  skip  or 

repeat 

The  eighth  element  contains  the  low  order  time  since  mid¬ 
night  in  seconds.  The  ninth  element  contains  the  high  order  time 
since  midnight. 


The  tenth  and  final  element  is  the  data  buffer  for  the  user. 


retrieval  program.  It  is  variable  in  length  and  its  length  is 
defined  as  the  second  element  in  the  record.  This  element  will 
contain  the  location  identifiers  requested  by  the  user. 
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2.4  RESIDENT  PDP-11/70®  SOFTWARE 

The  function  of  the  resident  software  on  the  PDP-11/70  is  to 
transmit  the  requested  weather  data  to  the  VRS  computer.  The 
accomplishment  of  this  process  requires  two  separate  and  distinct 
phases  of  data  handling.  The  first  is  the  translation  of  weather 
data  into  VRS  recognizable  pointers.  The  second  function  is  the 
selection  and  transmission  of  the  proper  data  to  the  VRS  computer. 

The  translation  of  the  raw  weather  data  into  VRS  pointers  and 
the  update  and  maintenance  of  those  files  is  referred  to  as  the 
"message  processing"  function.  The  selection  of  the  VRS  pointers 
and  their  subsequent  transmission  to  the  VRS  computer  is  the 
"retrieval"  function.  The  remainder  of  this  chapter  is  devoted  to 
description  of  these  two  functions. 


2.4.1  Overview  of  PDP-11/70  VRS  Message  Processing 

The  data  base  to  be  accessed  by  the  VRS  system  consists  of  data 
which  have  been  processed  from  a  raw  data  file,  KCW.DAT.  The 
processing  procedure  performs  a  translation  of  weather  data  which 
are  received  via  transmission  line  from  the  Federal  Aviation 
Administration's  Weather  Message  Switching  Center  (WMSC) ,  in  Kansas 
City,  Missouri.  The  translation  procedure  involves  the  following 
steps:  acquisition  of  the  proper  sub- file  to  access  the  reports  of 
a  particular  type;  identification  of  the  individual  reports  of  that 
type  and  correlation  to  a  location  identifier  (LOC.ID)  or  geographic 
region;  separation  (parsing)  of  the  recognized  words  within  the 
report,  and  use  of  a  dictionary  look-up  technique  to  translate  the 
ASCII  words  to  binary  representation.  The  binary  information 
represents  position  and  length  parameters  that  are  correlated  to 
digitized  words  and  phrases  which  are  stored  on  the  VRS  computer 
disk  files. 
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Figure  2*10  is  a  block  diagram  representation  of  the  translation 
procedures  (message  processing) . 

2.4.2  Data  Bases 

The  VRS  11/70  Software  uses  three  data  bases  and  a  global  common 
area  (GCA) .  The  data  bases  are  KCW . DAT ,  UDF . DAT ,  and  ERR. DAT.  The 
global  common  area,  called  VRSGLB,  is  a  shareable  global  task  area 
linked  to  by  the  VRS  processor  tasks.  VRSGLB  contains  input  and 
output  arrays  for  report  processing  and  a  map  array  for  report  block 
allocation  (See  Section  2. 4. 2. 2.1).  The  following  sections  describe 
KCW. DAT,  DDF. DAT,  and  VRSGLB;  however,  ERR. DAT  is  ‘described  later  in 
Section  2. 4. 3. 5.1. 


2. 4. 2.1  Kansas  City  Weather  Data  Base  *  The  weather  data  which  are 
to  be  translated  reside  in  a  disk  file,  KCW. DAT  at  the  PDP-11/70® 
system.  The  file  consists  of  an  index,  followed  by  thirteen 
mutually  exclusive  ASCII  sub-files,  each  of  which  is  a  circular 
buffer.  The  index  maintains  the  current  status  of  each  sub- file, 
with  respect  to  sub-file  boundaries,  last  disk  block  written,  last 
character  written,  and  circular  wrap-around  indicator.  Each 
sub- file  represents  a  different  weather  type,  except  in  the  case  of 
area  forecasts  and  significant  meteorological  events  which  reside  in 
the  same  sub-file  (see  Figure  2-11) . 

Each  sub- file  consists  of  headers  and  reports,  stored  by  weather 
type.  The  headers  and  reports  are  stored  in  the  sub-files  in  ASCII, 
exactly  as  received  from  the  WMSC.  The  weather  reporting  formats  of 
all  the  weather  types  are  described  in  the  National  Weather 
Service's  Operations  Manual. 
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RAW  DATA  TRANSLATION  PROCEDURE 


FIGURE  2-10:  Raw  Weather  Message  Processor 


2. 4. 2. 2  universal  Data  File  -  The  general  aviation  weather  from  the 
WMSC  line  is  translated  and  placed  in  one  file  on  the  11/70  disk. 
This  Universal  Data  File  (UDF)  contains  all  the  elements  required  to 
perform  the  processing  (translation)  of  the  raw  weather  data  into 
retrievable  VRS  "message-units. "  The  UDF  occupies  an  area  of  10,240 
blocks  of  disk  space  and  is  comprised  of  five  primary  components 
(see  Figure  2-12) . 


2. 4. 2. 2.1  Map  Array  -  a  map  array  of  5120  words  is  used  to  depict 
the  allocation  status  of  all  the  disk  blocks  in  the  file.  Each 
block  of  the  disk  is  represented  by  a  byte  in  the  map  array  and  its 
value  indicates  the  current  status  of  its  corresponding  data  block. 
There  are  four  general  conditions  represented  by  each  byte  in  the 
map  array.  They  are:  block  allocated  and  contains  a  valid  report; 
block  in  use;  block  not  in  use,  and  available  for  a  new  report.  The 
map  is  used  by  both  the  processing  and  the  retrieval  functions  of 
the  system.  The  map  is  read  into  the  Global  Common  Area  (GCA)  at 
system  initialization  time.  It  will  be  replaced  at  system  shut  down 
or  powerfail  time  (see  Figure  2-13).  In  its  initial  design,  the 
first  twenty  blocks  of  the  UDF  were  occupied  by  the  map  array.  vow, 
since  the  map  is  only  in  the  GCA,  these  twenty  blocks  are  free  for 
system  expansion. 


2. 4. 2. 2. 2  Regional  Report  Table  -  The  twenty-first  block  of  the 
Universal  Data  File  is  the  Regional  Report  Table  ( RRT) .  This  area 
(256  words)  will  contain  the  identifiers  for  all  regions  of  the  U.S. 
and  the  virtual  block  number  where  that  report  resides.  The 
dimension  of  the  array  will  be  the  number  of  regional  areas  by  the 
number  of  regional  report  types.  When  a  regional  report  is  being 
reported,  the  retrieval  software  will  first  determine  the  region  for 
the  requested  location  identifier,  then  get  the  report  from  the 
block  number  indicated  by  the  address  in  the  RRT. 


UNUSED 


20  blocks 


REGIONAL 
REPORT  TABLE 


LOCATOR  INDEX 
TABLE 


PROCESSED 
WEATHER  DATA 
IN 

MESSAGE  UNIT 
FORMAT 


WINDS  ALOFT 
DATA 


-  1  block 


233  blocks 


Up  to  four  message  units 

.  » 

(MU's)  per  block;  One 
report  per  block;  Blocks 
chained  for  reports 
larger  than  four  MU's 


8,246  blocks 


1,740  blocks 
Not  in  MU  format. 

The  first  1,271  blocks 
unused.  One  block  used 
for  Winds  Aloft  data 
status . 

468  data  blocks. 


FIGURE  2-12;  VRS  Universal  Data  File 
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Byte  1 


2 


3 


I _ I 


8,501 
1  I 


10,240 


Each  Byte  represents  the  status  of  the  corresponding 
Block  in  the  UDF .  The  first  254  and  the  last  1,740 
Indicator  Bytes  will  always  be  set  *  1  to  indicate 
the  presence  of  permanently  allocated  blocks. 


Key:  Byte  = 
-1 


-  block  available  for  use 

-  block  to  be  de-allocated:  report 
no  longer  valid 

-  block  contains  valid  report 


FIGURE  2-13:  VRSGLB  Map  Array 


2. 4. 2. 2. 3  Location  index  Table  -  The  next  area  contains  the  matrix 
of  location  identifiers  by  report  type.  It  is  an  area  of 
approximately  60  thousand  words  and  is  used  to  determine  the 
location  of  a  particular  report  within  the-UDF.  The  value  found  at 
the  juncture  of  the  report  type  requested,  for  a  given  location 
identifier,  represents  the  block  number  in  the  UDF  where  that  report 
has  been  placed  by  the  message  processor.  The  LIT  is  contiguous  in 
the  file  and  does  not  contain  any  header  or  trailer  information.  A 
stand-alone  program  (UDFPRG)  creates  the  LIT  array  and  the  program 
is  also  used  to  effect  any  updates  to  the  index  table.  (See  Figure 
2-14.) 

2. 4. 2. 2. 4  Message  Unit  Data  -  The  remainder  of  the  UDF  is  comprised 
of  the  processed  weather  data.  These  data  (with  the  exception  of 
the  Winds  Aloft  data)  reside  in  the  file  in  message  unit  format. 

That  is,  the  data  have  been  processed  and  the  reports  have  been 
translated  into  message  units  ready  to  be  retrieved  and  sent  to  the 
11/34.  All  retrieval  is  accomplished  by  using  block  I/O.  Each 
block  (512  bytes)  contains  up  to  four  message  units.  Each  message 
unit  is  prepended  by  eight  words  of  header  information  in  integer 
form.  Also,  each  block  contains  an  eight-word  header.  This  leaves 
room  for  four  54-word  message  units  (27  spoken  items)  per  block.  No 
block  ever  contains  message  units  from  more  than  one  report.  If  a 
report  requires  more  than  four  message  units,  several  blocks  may  be 
chained  together  to  link  the  message  units  together  for  the 
retrieval  function.  These  linked  blocks  need  not  be  contiguous  to 
carry  out  this  procedure.  The  link  indicator  in  the  header  contains 
the  block  number  of  the  lined  block  for  access  purposes.  The 
internal  format  of  the  message  units  consists  of  paired  voice 
pointers.  Each  recognized  word  of  the  original  report  is  converted 
to  a  location  pointer  and  corresponding  length  code  via  a  dictionary 
look-up  task.  The  pointers  and  lengths  are  then  put  in  the  message 
unit  and  stored  in  UDF.  (See  Figure  2-15.) 


For  each  entry  (LOC.ID)  a  line  contains:  LAT.  &  LON.  of  that  location;  the  region  in 
which  that  location  resides;  a  sub-region;  the  location  (block  number)  in  which  the 
current  reports  can  be  found.  A  zero  indicates  there  is  no  valid  report  of  that  type 
for  that  LOC.ID  in  the  system. 


SHAm  #M.P.  DAT  TIM 
#DTR  TIM  ” 


Block  Header 

Massage  Unit 
Header 


Message  Unit-1 
54  words 


Message  Unit-2 
Header 


Message  Unit-2 
54  words 


Message  Unit 
Header 


Message  Unit-3 
54  words 


#PTR  I 


Message  Unit 
Header 


Message  Unit-4 
54  words 


FIGURE  2-15:  Message  Unit  Format  for  a  256-Word  Block  in  UDF 
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2. 4. 2. 2. 5  Winds  Aloft  Data  -  The  last  1740  blocks  of  the  OOP 
contain  the  processed  Grid  Winds  Aloft  data.  The  Winds  Aloft  data 
are  not  stored  in  the  message  unit  format  as  is  the  rest  of  the 
processed  data,  but  rather  contain  numerical  values  of  temperature, 

X  and  Y  wind  vector  coordinates  for  various  altitude  levels  at 
specific  geographical  points.  The  further  processing  of  the  data 
into  message  unit  format  is  a  function  of  the  winds  retrieval 
software  (FDRTRV) .  This  is  due  to  the  nature  of  the  winds  data.  To 
report  the  wind  speed,  direction  and  air  temperature,  a  specific 
location  is  required  (latitude  and  longitude  of  a  location 
identifier)  and  an  altitude.  The  desired  values  are  then  obtained 
by  interpolation  of  data  for  specific  grid  points.  This  process  can 
only  be  done  at  retrieval  time.  The  winds  data  also  carry  a  header 
indicating  effective  time  and  date  of  the  forecast. 

2.4. 2.3  Initialization  of  Data  Base  fJDF.DAT  -  At  system  start-up  a 
stand-alone  program  is  run,  VRINIT,  to  initialize  the  DDF  data 
base.  First  the  map  array  is  initialized  by  setting  the  weather 
data  blocks  free,  with  all  others,  such  as  LIT  and  Wind  Data  Block, 
set  for  "in  use."  The  LIT  is  then  scanned  for  report  blocks  in 
use.  If  an  error  has  occurred  and  one  block  is  in  use  for  two 
locations  or  reports,  those  reports  are  zeroed.  After  initializing 
the  map  array,  the  KCW  file  pointers  for  the  VRS  are  reset  to  the 
last  major  weather  transmission  for  each  report  type. 


2.4.3  Raw  Data  Processing 

The  various  types  of  weather  data  have  significantly  different 
characteristics.  This  creates  the  need  for  multiple  processors, 
each  tailored  to  the  individual  requirements  of  the  data.  Each 
sub-file  of  raw  data  is  accessed  by  its  own  processor  routine.  The 
routines  are  in  the  form  of  overlaid  modules  to  be  used,  in 
conjunction  with  the  executive  routine  (Figure  2-10),  to  accomplish 
the  raw  data  processing. 


Each  processor  routine  will  be  constructed  to  account  for  the 
differences  in  structure  and  content  of  the  various  report  types. 
The  general  functions  of  recognizing  individual  words,  inserting 
header  of  "blocking"  words  and  performing  maintenance  procedures  on 
the  raw  data  file  will  be  common  to  all  processing  routines. 


2. 4. 3.1  Processor's  Executive  -  An  executive  structure,  called  VRS 
on  the  PDP-11/70®  maintains  control  of  the  execution  of  the 
individual  processor  routines.  The  routines  are  brought  in  and  used 
as  an  overlay  structure.  The  executive  continuously  monitors  the 
sub-file  activity  and  brings  in  each  processor  to  translate  the  data 
in  the  raw  KCW  file.  If  there  has  been  no  activity  {no  new  data 
have  been  received) ,  the  executive  continues  to  scan  through  the 
sub-file  indices.  If  there  has  been  activity  in  the  sub-files,  the 
appropriate  processor  is  invoked.  If  there  has  been  no  activity, 
the  executive  prints  the  processor  statistics  and  then  puts  itself 
in  a  wait  state  for  two  minutes.  After  this  time,  the  executive 
again  begins  polling  the  status  of  the  raw  data  file. 


2. 4. 3. 2  Message  Processing  Routines  -  Each  type  of  weather  data  is 
translated  by  a  separate  processor  routine.  Each  routine  is 
tailored  to  suit  the  raw  data  configuration  of  a  particular  report 
type.  These  routines  are  in  the  form  of  an  overlay  structure  so 
that  only  one  processor  is  in  execution  at  any  time.  An  overlay 
consists  of  the  main  processor  and  several  supporting  subroutines. 
Under  the  RSX-llD  system,  this  procedure  is  carried  out  similar  to 
regular  Fortran  subroutine  calls  after  the  overlay  threading  has 
been  accomplished  during  the  task-build  phase. 

Each  processor  executes  the  translation  procedure  on  a  full 
report  basis.  A  complete  report  is  translated  and  all  recognized 
words,  plus  any  "blocking"  words  required,  are  placed  in  a  single 
array.  This  array  of  words  is  returned  for  dictionary  translation. 
When  the  entire  report  has  been  processed,  the  processor  returns 
program  control  to  the  executive. 
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The  current  weather  processors  available  are  for  surface 
observations  (SA)  and  surface  observation  remarks,  terminal 
forecasts,  and  winds  aloft.  Following  is  a  brief  description  of  the 
processor  design  as  it  interacts  with  the  VRS  Executive.  For  a  more 
detailed  description  of  weather  data  and  content  checks  for  each 
processor,  see  Reference  7,  "The  Ten  Channel  VRS  Processor  Design 
Report. " 


2. 4. 3. 2.1  Surface  Observation  (SA)  Processor  -  The  SA  processor  is 
an  overlay  module  invoked  by  the  VRS  processor  executive.  The 
function  of  this  module  is  to  unpack,  decode,  and  translate  surface 
observation  reports  into  ASCII  text.  The  text  is  then  translated 
into  voice  pointers  and  stored  in  a  data  base.  The  procedure  used 
in  decoding  the  SA  data  is  of  a  scan  and  extract  type.  Initially, 
the  report  is  scanned  to  determine  the  presence  of  four  critical 
fields.  These  are  the  SA  location  identifier,  the  sky  cover,  the 
visibility,  and  the  wind  field.  During  this  process  pointers  are 
set  delimiting  the  fields  present.  After  this  is  done,  the 
individual  components  of  the  report  are  extracted,  decoded,  and 
placed  in  the  output  list.  During  this  extraction  process,  limit 
and  quality  checks  are  applied  to  the  data. 

The  SA  Processor  consists  of  a  main  routine  (VRSSA)  and  four 
extraction  subroutines  (SfJBFLD,  VISWX,  SKY,  EXTHED)  .  The  VRSSA  main 
routine  begins  the  process  by  calling  each  of  the  extraction 
routines.  The  routines  return  translated  pieces  of  the  SA  report. 
Then,  VRSSA  puts  the  pieces  together  in  the  proper  order.  If  any  of 
the  routines  has  discovered  a  serious  error  (one  that  leaves  some 
doubt  regarding  the  validity  of  the  translation)  ,  or  if  any  of  the 
key  fields  is  missing,  VRSSA  will  flag  the  report  as  erroneous  and 
notify  the  executive  that  the  report  should  not  be  placed  in  the 
processed  weather  data  base. 
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2. 4. 3. 2. 2  Surface  Observation  Remarks  Processor  -  After  the  SA 
Processor  has  decoded  the  report,  the  SA  Remarks  Processor  Overlay 
is  called  to  decode  the  remaining  remarks  of  the  report.  Then  the 
dictionary  look-up  task  is  called  to  translate  the  entire  report. 

The  SA  Remarks  processor  uses  a  •’key-word'’  approach  to  translating 
the  data.  The  main  routine  (VRRMK)  extracts  one  word  at  a  time, 
using  a  blank  character  as  a  delimiter.  The  process  begins  at  the 
start  of  the  remarks  field  specified  to  VRRMK  through  a  call 
argument  received  from  SA  subroutine  srjBFLD. 

The  remarks  processor  is  a  separate  overlay  within  the  VRS 
program.  It  resides  at  the  same  level  as  the  other  processor 
modules. 

The  processor  always  begins  scanning  the  data  from  the  left  and 
proceeds  to  the  end  of  the  remarks  field.  The  beginning  is  usually 
one  character  past  the  end  of  the  altimeter  field.  If  the  altimeter 
is  missing,  the  beginning  is  assumed  to  be  one  character  past  the 
end  of  the  wind  field.  The  main  processor  routine  (VRRMK)  extracts 
a  ‘’word**  from  the  raw  data.  A  "word"  in  this  context  is  any  string 
of  characters  preceded  by  and  followed  by  a  blank.  The  word  may  be 
all  numeric,  all  alpha,  alpha-numeric,  or  alpha-numeric  with  special 
characters,  when  alpha  or  alpha-numeric  data  are  found  in  the  word, 
the  program  then  attempts  to  identify  a  "key"  within  the  word.  If  a 
key  is  found,  then  VRRMK  invokes  the  proper  subroutine.  Each 
subroutine  orocesses  a  particular  type  of  remark.  The  subroutine 
receives  the  array  and  the  pointer  to  where  its  key  is  found.  The 
subroutine  knows  if  preceding  or  following  information  is  required 
and  can  step  along  the  raw  data  to  extract  all  the  information 
pertinent  to  that  particular  type  of  remark,  when  the  remark  has 
been  translated,  the  subroutine  moves  the  pointer  to  where  it  ended 
and  returns  to  VRRMK. 

At  this  point,  the  process  is  begun  again.  This  process 
continues  until  all  remarks  have  been  processed  or  until  an 
unrecognized  or  all-numeric  field  signals  the  end  of  remarks  and 
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beginning  of  additive  data.  Each  remark  field  is  handled  separately 
with  no  restrictions  to  sequence  or  amount  of  field  type. 

If  a  word  containing  alpha  characters  is  extracted  and  no  key  is 
found  in  that  word,  it  is  assumed  to  be  free  text  and  is  entered 
into  the  output  array  as  such. 

Using  this  approach,  highly  coded  remarks  or  free  text  in  any 
sequence  or  mix  can  be  translated.  Whenever  a  free-text  entry  is 
made,  the  processor  notes  its  position  in  the  raw  remark.  These 
pointers  are  saved  and  used  by  the  on-line  editor.  It  can  be 
assumed  that  if  an  error  occurs  during  the  dictionary  look-up  task, 
it  would  be  caused  by  a  free-text  entry  and  not  by  coded  processing. 

2. 4. 3. 2. 3  Terminal  Forecast  (FT)  Processor  -  The  principal 
objective  of  the  raw  weather  data  processor  array  is  to  insure 
reliability  of  the  processed  weather  report.  The  Terminal  Forecast 
(FT)  Processor  must  be  able  to  discern  the  properties  of  each  raw 
weather  data  field  to  be  processed  such  that  the  probability  of 
misrecognition  is  reduced  to  zero. 

It  is  better  for  the  processor  to  flag  a  weather  field  as  a 
non-recognition  error  than  to  process  it  incorrectly.  The 
processor,  however,  must  be  sophisticated  enough  to  reduce  the 
amount  of  non-recognition  errors  being  sent  to  the  editor. 

In  order  to  achieve  this  goal  of  zero  misrecognition  errors  and 
a  low  amount  of  non-recognized  fields,  the  FT  processor  is  designed 
not  only  to  determine  what  a  field  is,  but  more  importantly,  what  a 
field  is  not. 

The  Terminal  Forecast  (FT)  Processor  must  process  the  eight 
fields  contained  in  an  FT  report.  The  FT  fields  are: 
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1}  Station  Designator 

2)  Bulletin  Notice 

3)  Date- Time  Group 

4)  Sky/Ceiling  Cover 

5)  Visibility/Precipitation 

6)  Winds 

7)  Remarks 

8)  Time. 

An  FT  report  always  contains  a  heading  of  station  designator,  a 
possible  bulletin  notice,  and  a  date- time  group.  The  body  of  the 
report,  however,  contains  multiple  time  groups  in  which  the 
remaining  fields  may  or  may  not  occur.  Also,  the  field  may  be 
embedded  within  a  remarks  field,  in  order  to  handle  these 
discrepancies  efficiently,  the  processor  routine  calls  a  recognition 
routine  for  each  field  as  the  characters  are  read  in  from  the 
array.  Each  recognition  routine  scans  the  "character"  group  and 
reports  one  of  three  conditions:  (1)  it  is  definitely  the 
recognizer's  field;  (2)  it  is  probably  the  recognizer's  field;  or 
(3)  the  field  is  not  recognized  at  all.  The  character  group  is  then 
processed  by  the  appropriate  field  processor  according  to  the 
following  protocol. 

A  single,  def ini te  recognition  of  a  field  is  flagged  as  the 
correct  field,  even  though  other  routines  may  have  reported  probable 
recognition,  if  there  has  been  no  definite  recognition,  then  a 
single,  probable  recognition  is  flagged  as  the  correct  field.  All 
other  conditions  cause  the  editor  to  be  flagged.  Thus,  the 
processor  is  able  to  make  a  finer  distinction  between  fields  whose 
forms  sometime  seem  identical  and  to  recognize  fields  whose  forms 
frequently  change  even  within  a  single  time  frame. 


2. 4. 3. 2. 4  wind;;  Mo(»  i»i  ooo.nsor  -  The  Winds  Aloft  Processor  (VRSPD) 
accepts  the  winds  aloft  data  in  the  order  that  they  are  transmitted 
and  decodes  them  into  temperature,  X  and  Y  coordinates  of  the  wind 
vector,  and  additionally  for  Level  2  data,  tropopause  height.  These 
data  are  written  to  the  Universal  Data  Pile  along  with  header 
information  containing  amendment  designation,  forecast  day  and  time, 
transmission  day  and  time,  blockette  header  time  code,  and  a  file 
wrap  index.  The  record  location  of  the  data  within  the  UDF  is 
determined  by  the  blockette  number,  altitude  level,  and  forecast 
time  code. 

The  file  structure  for  the  Winds  Aloft  is  organized  so  that  data 
for  six  forecast  time  periods  starting  from  a  time  zero  reference 
point  are  available  for  retrieval.  This  is  done  by  having  a  file 
structure  which  wraps  around  continuously,  with  each  new  forecast 
period  data  overlapping  the  previous  forecast  period  data  in  the  UDF 
where  the  data  are  for  the  same  forecast  time  period  measured  from 
the  zero  reference  point. 

This  file  structure  also  allows  accommodation  of  transmissions 
with  missing  or  erroneous  data.  One  block  in  the  UDF  is  set  aside 
for  storing  file  record  pointers,  special  information  flags,  and 
time  data  for  both  the  Winds  Aloft  processing  program  and  retrieval 
program.  The  information  contained  in  this  "master"  block  allows 
the  Winds  Aloft  programs  to  function  correctly  after  periods  of 
computer  down  time  and  allows  correct  storage  and  retrieval  of 
processed  data  at  all  times. 


2. 4. 3. 3  DICT  -  The  dictionary  task  translates  ASCII  text  to  a  group 
of  speech  file  pointers.  The  task  is  installed  and  can  be  used  by 
any  caller.  The  data  is  entered  in  VRSGLB  array  PDICIN  if  called  by 
the  VRS  processor  and  the  speech  file  pointers  are  returned  in  the 
array  PDICO.  When  called  by  FDRTRV  for  winds  retrieval,  the  VRSGLB 
array  is  ATADII  and  output  appears  in  ATADIO.  DICT  uses  a  binary 
search  algorithm  to  find  the  data.  It  returns  the  speech  file 
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pointers  and  a  word  containing  the  length  in  bytes  of  the  translated 
pairs.  On  the  event  of  a  failure  of  translation,  the  routine 
returns  pointers  to  where  the  text  was  in  the  original  string  which 
could  not  be  translated. 


2. 4. 3. 3.1  Dictionary  Structure  -  The  raw  data  in  ASCII  format  must 
be  put  in  a  form  recognizable  by  the  VRS  system  before  it  can  be 
spoken.  This  is  accomplished  by  using  a  core  resident  dictionary 
and  corresponding  look-up  procedure. 

The  dictionary  contains  the  VRS  spoken  word  index  number  and  a 
length  code  for  each  word  or  phrase  that  can  be  spoken  by  the  VRS 
unit.  The  dictionary  program  uses  a  binary  search  to  locate  the 
proper  index  and  length  code  for  each  recognized  ASCII  word  it 
receives. 

The  look-up  procedure  is  carried  out  as  an  installed  task.  The 
task  is  invoked  by  the  processor  executive  as  stand-alone  and  is  not 
re-entrant.  The  dictionary  task,  when  activated,  is  presented  with 
the  array  of  recognized  words  prepared  by  the  individual  processor 
routine.  The  dictionary  task  proceeds  to  create  a  list  of  length 
codes  and  pointers  on  a  one-for-one  basis  and  returns  this  list  to 
the  executive  by  placing  it  in  the  GCA  array.  Also,  an  error  flag 
is  set  to  indicate  if  the  report  contained  any  words  that  could  not 
be  found  in  the  VRS  dictionary  file.  Control  is  then  returned  to 
the  executive. 


2. 4. 3. 4  VRS  OUT  -  A  separate  installed  task  VRSOrJT  is  called  by  the 
VRS  executive  to  write  the  array  of  dictionary  pointers  into  the 
DDF.  The  array  is  stored  in  the  VRS  global  common  area  by  the 
dictionary.  Dpon  being  called  by  VRS  (11/70)  to  output  a  report, 
first,  VRSOrJT  checks  for  a  Surface  Observation  (SA)  special  report. 
If  the  report  is  special,  it  is  appended  to  the  current  SA  report  by 
the  subroutine  SASPSC. 
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The  basic  component  of  speech  in  the  system  is  the  message 

unit.  Each  message  unit  can  contain  up  to  27  pairs  of  VRS  pointers 

.  (i.e.,  27  spoken  words  or  phrases).  During  the  retrieval  process, 

the  messages  units  are  taken  from  the  data  file  (fJDF)  and 
•  — 

*  transmitted  to  the  VRS  computer.  The  format  of  a  transmitted 

message  unit  is  shown  in  Figure  2-16. 

After  a  report  has  been  translated  by  the  processor,  the  array 
of  VRS  pointers  is  taken  by  the  block  formatting  routine  (BLCR8) . 
This  subroutine  places  the  paired  VRS  pointers  in  the  message  unit 
format  and  creates  an  output  block.  Each  message  unit  is  prepended 
with  appropriate  header  information  for  its  report  type.  The  format 
of  a  message  unit  within  the  fJDF  is  shown  in  Figure  2-16. 

The  map  array  is  scanned  for  free  rjDF  blocks  and  their 
corresponding  map  bytes  are  set.  The  subroutine  IOBLCK  is  called  to 
output  the  block  to  the  fJDF.  This  procedure  is  repeated  until  the 
entire  array  is  output.  A  chain  word  is  used  to  indicate  the  next 

« 

block  of  the  sequence  of  blocks  with  zero  indicating  the  last 
block.  The  new  report  block  then  replaces  the  old  report  in  the 
<  LI T.^ 'The  old  block  number  and  its  chained  block  map  values  are 

decremented  to  free  the  unused  blocks. 

Before  the  VRS  executive  starts  its  wait  cycle,  it  calls  VRSODT 
to  exit,  when  VRSOfJT  receives  an  exit  command,  it  first  scans  the 
map  array  for  unused  blocks  (bytes  equal  to  0,  see  Figure  2-13).  The 
free  indicator  (bytes  equal  to  -1)  is  set  for  each  unused  block. 
VRSOfJT  then  exits  from  memory. 

VRSPURG  -  The  function  of  the  subroutine  VRSPfJRG  is  to  purge  Hourly 

\  * 
i  Surface  Observation  (SA's)  and  Terminal  Forecast  (FT's)  reports  from 

l  the  data  base  when  they  are  considered  to  be  too  old  and  no  longer 

I  *  valid.  The  routine  is  called  by  VRSOfJT  once  each  hour  durina  the 

t 

i  time  period  of  15  minutes  past  the  hour  to  45  minutes  past  the 

hour.  As  most  of  the  SA  and  FT  reports  come  in  between  on-the-hour 
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FIGURE  2-16:  Transmitted  Message  Units 
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and  15  minutes  past  the  hour,  calling  VRSPfJRG  in  the  time  frame 

given  previously  allows  for  new  data  to  replace  old  data  in  a  normal 

,  fashion  and  reduces  the  workload  of  VRSPfJRG  by  eliminating 

unnecessary  purging.  Hourly  Surface  Observations  are  purged  when 
*  — 

they  have  become  more  than  2  hours  old.  Terminal  Forecasts  are 
purged  when  they  have  become  more  than  8  hours  old. 

j 

Each  time  VRSPURG  is  called,  it  scans  every  SA  and  FT  report  in 
each  page  of  the  locator  index  table  (LIT) .  When  a  report  is  found 
to  require  purging,  VRSPfJRG  calls  the  subroutine  WOTAVB.  The  sole 
purpose  of  NOTAVB  is  to  create  a  standard  message  of  "current  report 
not  available"  to  replace  the  report  to  be  purged.  It  does  this, 
returning  the  fJDF  block  number  of  the  canned  message  to  VRSPfJRG.  . 
VRSPfJRG  then  replaces  the  old  SA/FT  repoft  block  number  in  the  LIT 
with  the  canned  message  block  number.  When  every  LIT  page  has  been 
scanned,  VRSPfJRG  returns  to  VRSOfJT. 

2. 4. 3. 5  Data  Edit  Position  -  When  a  report  is  determined 
untranslatable  by  a  weather  processor,  the  report  is  written  to  an 
,  error  file.  The  Data  Edit  Position  (DEP)  software  reads  the  report, 

displays  it  on  a  screen,  and  allows  a  DEP  operator  to  correct  it. 

After  an  operator  has  made  all  the  corrections  to  the  report,  it 
is  written  into  another  area  in  the  file  for  later  translation  by 
the  VRS  weather  processor.  The  data  edit  position  software  is 
composed  of  three  major  components;  terminal  tasks,  (DEPTT) ,  a 
service  task,  (OEPST) ,  and  a  data  base,  (ERR. DAT).  The  following 
sections  describe  the  functional  description  of  the  Data  Edit 
Position.  For  a  complete  description  of  the  Data  Edit  Position, 
including  the  Data  Edit  commands,  see  Reference  8. 
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2. 4. 3. 5.1  Error  File,  ERR. DAT  -  The  erroneous  and  corrected  reports 
are  kept  in  the  error  file,  ERR. DAT.  The  file  is  structured  into 
three  parts:  the  pointer  blocks,  the  error  subfiles,  and  the 
corrected  subfiles.  This  file  is  created  by  the  stand-alone  program 
ERRCRT. 

The  first  section  is  contained  in  the  first  two  blocks  of  the 
file.  The  first  block  contains  the  VRS  executive  read  and  write 
pointers  to  each  subfile.  The  second  block  contains  the  DEP  Service 
Task  read  and  write  pointers  for  the  subfiles.  Each  subfile  has  a 
five  parameter  pointer  set.  These  are  the  subfile  start  and  end 
block,  the  next  report  block  and  integer  offset,  and  the  report 
sequence  number.  The  only  exception  to  this  is  that  the  VRS  read 
pointers  contain  the  next  report  block  and  byte  offset  to  correspond 
to  its  GETRPT  software.  The  next  section  of  the  file  is  the 
circular  subfiles  containing  the  error  reports  received  from  the  VRS 
weather  processors.  Each  subfile  contains  a  report  type. 

The  third  section  of  the  file  is  identical  to  the  error  file 
except  that  this  section  contains  the  corrected  reports  received 
from  the  Data  Edit  Position. 

2. 4. 3. 5. 2  Data  Edit  Position  Service  Task  -  The  DEP  Service  Task 
(DEPST)  is  a  communications  driven  service  module  which  provides 
information  for  the  VRS  and  interfaces  between  the  error  file  and 
the  DEP  terminal  tasks.  All  requests  for  service  are  queued  by  the 
RSX-11D  operation  system  and  are  handled  in  the  order  in  which  they 
occur.  Hence,  the  DEPST  is  dedicated  to  a  specific  task  which  is 
making  a  request  until  the  request  is  honored.  After  performing  the 
indicated  service,  DEPST  suspends  itself  until  more  requests  are 
generated. 

There  are  five  types  of  requests  sent  to  DEPST,  one  by  the  VRS 
(11/70)  and  four  from  DEPTT.  The  VRS  executive  only  requests  the 
service  task  to  update  its  pointers  to  the  corrected  report  subfiles. 
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When  a  terminal  task  enters  memory,  it  requests  the  Service  Task 
to  assign  it  buffer  space  in  the  Global  Common  Area.  The  Service 
Task  keeps  track  of  which  terminal  has  been  assigned  to  each  buffer 
space  of  256  words,  fjpon  request,  the  Service  Task  places  the  next 
error  report  into  this  common  area  for  the  Terminal  Task.  The 
Service  Task  obtains  the  error  report  from  the  proper  error 
subfile.  It  checks  the  date  and  time  of  the  error  report  and  the 
current  report  in  the  CDF  for  the  corresponding  location.  The  error 
report  is  dropped  if  it  is  not  the  most  recent  report  in  either 
file.  This  insures  that  the  operator  would  not  have  to  correct  an 
already  expired  report.  When  a  report  has  been  corrected,  the 
Terminal  Task  requests  it  to  be  filed.  The  Service  Task  files  the 
report  in  the  error  file  and  updates  the  pointers.  A  DEPTT  requests 
exit  permission  when  a  DEP  operator  types  the  "EXIT"  command. 

rjpon  receiving  the  exit  request,  the  DEPST  frees  the  assigned 
buffer  space.  If  there  are  no  other  terminal  tasks  being  serviced, 
DEPST  also  exits  memory. 


2. 4. 3. 5. 3  Data  Edit  Position  Terminal  Tasks  -  The  DEPTT' s  are 
dedicated  tasks  which,  when  run,  communicate  with  the  DEP  operators 
by  way  of  CRT  displays.  The  tasks  only  interface  with  the  rest  of 
the  DEP  system  through  data  stored  in  the  Global  Common  area  and  the 
RSX-11D  Send  and  Receive  commands,  which  the  Terminal  Tasks  use  to 
request  operations  from  the  Service  Task.  After  initialization,  a 
Terminal  Task  first  requests  to  be  assigned  buffer  space  by  the 
DEPST.  when  this  has  been  completed,  the  Terminal  Task  then  awaits 
input  from  the  operator  requesting  a  report  to  edit.  With  this 
information,  the  Terminal  Task  requests  the  report  from  the  Service 
Task.  The  report  is  placed  into  the  Global  Common  Area  assigned 
buffer  (see  Figure  2-17).  The  operator's  edit  commands  are  then 
performed  on  the  report  until  a  file  or  drop  report  is  received.  If 
another  report  is  requested,  this  process  is  continued.  When  all 
error  reports  have  been  corrected,  or  when  the  operator  types  the 
exit  command,  the  Terminal  Task  notifies  the  Service  Task,  and  then 
exits  memory. 
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FIGURE  2-17:  Data  Edit  Configuration 


2.4.4  PDP-11/70  Retrieval  Task 


The  twenty- channel  resident  PDP-11/70  retrieval  software  is  a 
multi-channel  program  responsible  for  receiving  and  interpreting 
results  from  the  VRS  computer  and  honoring  those  requests  by 
supplying  weather  information  from  the  weather  data  base.  The 
inputs  from  the  VRS  computer  take  the  form  of  specific  requests  for 
message  unit  elements  of  the  weather  data  base  (demand  response) ,  or 
of  supplying  the  parametric  information  defining  the  briefing 
requested  by  the  user  (briefing  request  message  Section  2. 1.2.1). 

It  is  the  responsibility  of  the  retrieval  task  to  access  the 
weather  data  base  independently,  building  briefing  tables  for 
asynchronous  access  for  the  VRS  computer.  The  process  of 
constructing  briefing  tables  may  occur  several  times  during  each 
user  session  (briefing)  in  order  to  progress  through  briefing 
phases.  Each  briefing  phase  (sub-briefing)  is  delineated  by  a 
briefing  request  message  #2  (Section  2. 1.2.1).  The  VRS  computer 
employs  the  briefing  request  message  #2  to  cause  the  retrieval  to 
build  a  sub-briefing.  When  the  VRS  computer  has  requested  all  of 
the  message  units  it  requires  (dependent  upbn  user  Touch-Tone 
interactions)  as  a  result  of  briefing  request  message  #2,  it  may 
issue  a  subsequent  briefing  message  #2,  to  cause  the  retrieval 
program  to  build  another  briefing  table.  During  a  channel  briefing, 
there  is  only  one  briefing  table,  the  progressions  from  sub-briefing 
to  sub-briefing  are  conducted  only  in  a  forward-going  manner.  That 
is,  the  VRS  computer  may  not  request  message  units  from  the  briefing 
table  for  any  briefing  request  message  #2  prior  to  the  briefing 
request  message  #2  currently  being  processed.  Figure  2-18  shows  a 
baseline  structure  for  the  PDP-11/70  retrieval  task. 


2. 4. 4.1  Retrieval  Task  Organization  -  In  order  to  take  advantage  of 
the  RSX11D/V6B,  event-driver,  multi-programming  system,  the 
PDP-11/70  retrieval  task  is  comprised  of  three  basic  components:  an 
executive  level;  an  interrupt  level;  and  an  internal  data  base  used 
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Weather  Retrieval  Software 


for  communication  between  the  executive  and  interrupt  levels,  and 
also  used  for  inter -computer  communication,  disk  transfers,  tables, 
flags,  and  variables  of  processing.  The  interrupt  level  will  be 
defined  as  asynchronous  trap  (AST)  processing.  With  reference  to 
;  Section  2.2,  the  executive  level  may  be  considered  as  analogous  to 

the  VRS  computer  background  processing  and  the  AST  level  may  be 
•  considered  as  analogous  to  the  VRS  computer  completion  routine 

processing . 

2. 4. 4. 1.1  Retrieval  Task  Data  Base  -  To  maintain  channel 
independence  and  integrity,  a  data  base  consisting  of  eight  hundred 
words  per  channel  is  used  for  all  channel  dependent  variables, 
flags,  I/O  areas,  tables,  etc.  In  addition,  another  area  consisting 
of  twenty  buffers  of  sixty-four  bytes  is  maintained  as  a  queued 
input  buffer,  for  receiving  VRS  computer  commands. 

* 

.  2. 4. 4. 1.1.1  Input  Buffer  Queue  -  The  input  buffer,  labeled  BUFFER, 

consists  of  forty  elements.  Each  element  contains  sixty-four 
characters,  where  the  first  two  bytes  are  used  as  a  linkage  thread, 
and  the  last  sixty-two  are  used  for  storing  the  commands  received 
from  the  VRS  computer. 

The  threads  are  used  to  maintain  information  as  to  the  logical 
assignment  of  the  elements.  Two  list  headers  (queues)  are 
maintained.  Each  list  header  contains  two  words,  where  the  first 
word  is  used  to  point  to  the  top  of  the  list,  and  the  second  word  is 
used  to  point  to  the  tail  (end)  of  the  list.  The  two  list  headers 
are  used  for  maintaining  a  queue  of  "in  use"  elements,  and  for 
maintaining  a  queue  of  "available"  elements. 

T. 

By  the  process  of  maintaining  the  elements'  threads,  buffer 
elements  may  be  accessed  in  the  order  in  which  the  VRS  computer 
*  transmits  commands,  thereby  ensuring  that  the  PDP-11/70®  retrieval 

program  services  the  VRS  computer  requests  in  the  order  presented. 
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This  does  not  assure  responses  to  the  VRS  computer  will  be  in  the 
order  of  received  requests.  8ecause  of  the  length  of  time  of 
command,  services  will  not,  in  general,  be  uniform. 

Figure  2-19  is  a  representation  of  the  input  buffer,  and  the  two 
list  headers.  The  figure  assumes  that  the  queue  for  ■’in-use'' 
elements  is  labeled  RETQCE  and  the  queue  for  "available"  elements  is 
labeled  FREEPL.  The  linkage  threads  are  the  element  identifiers, 
and  the  thread  ends  with  the  element  whose  linkage  is  zero.  The 
figure  shows  that  elements  2,  3,  and  4  are  "in-use",  element  5  is 
currently  assigned  as  the  input  area  for  the  current  outstanding 
read  function,  and  the  remaining  elements  are  "available."  They  will 
be  assigned  in  the  order:  element  6  through  element  20  in  order, 
then  element  1.  If  any  "in-use"  element  were  to  be  released,  it 
would  be  placed  at  the  tail  of  the  FREEPL  queue  and  element  l's 
linkage  thread  would  be  replaced  with  the  freed  element's 
identifier,  whose  linkage  thread  would  be  zero. 

2. 4. 4. 1.1. 2  Channel  Status  Block  -  In  order  to  maintain  complete 
channel  independence,  and  to  maintain  briefing  state  information  for 
each  channel,  a  sixteen  thousand  word  block  of  memory  is  allocated, 
eight  hundred  words  per  channel.  The  channel  status  block  (CS8)  is 
used  for  maintaining  all  the  information  relative  to  the  operation 
of  the  channel. 

All  flags,  status  indicators,  disk  transfer  buffers,  VRS  output 
buffers,  etc.,  are  contained  in  this  area.  In  addition,  all  driver 
tables  and  parametric  information  required  for  constructing  the 
desired  briefing  are  in  this  area. 

The  retrieval  program  constructs  the  briefing  directly  onto  the 
CSB.  It  consists  of  a  list  of  virtual  disk  blocks  of  the  weather 
data  base.  The  following  items  are  entries  in  the  CSB. 


Linkage 

Thread 


Received  Characters 


Element 


RETQUE :  2  (head)  FREEPL:  6  (head) 

4  (tail)  1  (tail) 

FIGURE  2-19:  BUFFER,  RETQUE,  FREEPL 
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•  DIOA  Disk  I/O  Area 

This  area  occupies  256  words  and  is  used  as  the  block 
transfer  area  from  disk  into  memory. 

•  QB  This  word  contains  the  number  of  the  BUFFER  element 

currently  in  use  for  the  channel.  It  is  saved  for  the 
requirement  that  element  numbers  must  be  retrievable 
so  that  they  can  be  used  in  the  buffer  release  call. 

•  MODE  This  word  is  used  to  save  the  mode  under  which  the 

current  briefing  is  operating. 

•  DIAGP  This  word  is  used  to  maintain  the  next  available  byte 

position  in  the  diagnostic  buffer  for  the  channel. 

•  CR8T  Channel  Response  Block  Table  (Briefing  Table).  This 

is  a  table  which  contains  the  fJDF  virtual  block  number 
of  each  block  required  for  the  briefing  currently  in 
progress.  Every  block  is  entered  regardless  of 
whether  it  is  the  start  of  a  linked-block  indicating 
report  continuation.  The  table  is  constructed  in  a 
top-down  manner  in  which  each  succeeding  entry 
logically  follows  its  predecessor  for  purposes  of  the 
briefing  presentation.  There  is  no  relationship  of 
the  virtual  block  numbers  to  other  virtual  block 
numbers,  other  than  briefing  order.  (Size  300  words.) 

•  CRMUT  Channel  Response  Message  Unit  Table.  Because  of  the 

requirement  to  deliver  message  units  by  number  and 
because  of  the  construction  of  the  data  base  in  which 
each  block  may  contain  either  one,  two,  three  or  four 
message  units,  a  table  of  cumulative  count  of  message 
units  must  be  maintained.  The  CRMUT  contains  the 
least  message  unit  (LM)  number  and  the  greatest 
message  unit  (GMU)  number  in  the  briefing  message  unit 


sequence  £or  the  current  block.  A  demand  message 
unit,  not  within  the  range  of  the  CRMUT/  will  cause 
the  appropriate  block  to  be  read. 

•  DIAGB  This  is  a  sixty-four  word  area  into  which  diagnostic 

messages  are  constructed.  These  are  the  messages 
which  are  transmitted  to  the  VRS  computer  for  the 
purpose  of  either  indicating  command  compliance  or  for 
indicating  why  compliance  is  not  possible 
(Section  2.1.3) . 

e  ALT  This  word  contains  the  requested  altitude  for 

processing  Winds  Aloft  Data  and  for  determining  the 
filtering  of  reporting  points  along  a  flight  path. 

•  HOURS  This  word  contains  the  "forecast-ahead"  time  for  which 

Winds  Aloft  Data  are  required. 

•  LMUS  This  word  contains  the  number  of  the  last  message  unit 

sent. 

e  RPMSK  This  is  a  table  of  requested  report  types  and  is 

constructed  from  the  information  received  in  a  BRM2 
transmission . 

e  RLOCS  This  is  a  table  of  sixteen-word  entries  which  are  the 
locator  index  table  (LIT)  entries  corresponding  to  the 
requested  location  identifiers.  The  entries  are 
extracted  from  the  locator  table  index  at  the  time  of 
location  identifier  confirmation.  They  are  held  in 
the  channel's  status  block  area  in  order  to  obviate 
the  necessity  for  reading  the  disk  each  time  a  report 
isolation  is  required.  That  is,  the  function  of 
reading  a  report  requires  only  reading  the  report  and 
not  reading  the  locator  index  table  again. 


•  LOCPTR  This  is  a  position  indicator  for  accessing  the  RLOCS 

tables. 

•  BRMlE  Error  indicator  for  briefing  request  message  1.  The 

indicator  may  be  set  for  a  variety  of  reasons: 
request  out  of  format;  improper  mode;  illegal  location 
identifier  (s) ;  improper  channel,  etc.  The  indicator 
is  used  as  a  switch  at  the  end  of  decoding,  as  to 
whether  a  confirmation  message  is  required  or  a 
diagnostic  message. 

LST10C  Index  to  the  number  of  location  identifiers  residing 
in  th®  O  jQCS  _ 

•  S^aGE  The  briefing  stage  currently  attained.  Because  the 

retrieval  orocram  ooerates  mainly  as  a  series  of  AST 
comoletiors.  the  stage  indicator  is  used  as  the 
director  for  the  next  function  to  be  performed. 

2. 4. “.1.2  Command  Decoder  (COYDEC)  -  The  executive  level  of  the 
retrieval  program,  called  the  command  decoder ,  is  responsible  for 
recognizinc  the  existence  of  a  rotate  received  from  the  VRS 
co-outer ,  and  initiative  aoorepr  late  action  which  will  cause  the 
command  to  b°  \ —cl erne n  tec  . 

In  order  to  accomplish  its  function,  COM2 EC  is  required  to  parse 
the  input  commands  'Section  2. 1.2.1),  checking  for  both  form  and 
content.  Our  ire  the  process  of  scanning  the  input  command,  the 
tables,  fl acs,  and  indicators  of  the  channel  status  block  (previous 
aectio-h  are  initialised  and  constructed  in  conformance  with  the 
specified  cc— and .  Also,  the  diagnostic  area  is  initialized  and  its 
co1'  s  tr  uc  t  io~  is  star  ted . 
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The  command  decoder  remains  in  a  suspended  state  until  resumed 
by  the  asynchronous  trap  handler  which  receives  the  communications 
line  inputs.  The  input  is  dequeued  from  the  input  buffer  area, 
BOFFER  (Section  2.4.4. 1.1.1) ,  and  the  channel  status  block,  CSB 
(Section  2. 4. 4. 1.1. 2) ,  is  constructed.  The  system  is  designed  such 
that  each  input  request  causes  a  series  of  disk  accesses  which  are 
processed  on  the  AST  level  (Section  2. 4. 4. 1.3).  The  command  decoder 
is  not  required  to  take  any  further  action  upon  an  input  request 
beyond  causing  the  initial  disk  access.  The  disk  access  will  in 
turn  cause  further  disk  accesses  for  the  purpose  of  either  accessing 
the  locator  index  table  (for  location  identifier  verification) ,  or 
accessing  a  block  of  data  representing  processed  weather  data  (for 
demand  response  delivery) . 

After  the  disk  access  is  initiated,  the  command  decoder  dequeues 
the  next  input  command.  Tf  no  input  command  has  been  received,  the 
command  decoder  suspends  itself  (to  be  resumed  by  the  communications 
line  AST  handler) . 


2. 4. 4. 1.3  AST  Processing  -  This  level  of  processing  may  be 
considered  as  analogous  to  the  RT-11  completion  routines  described 
in  Section  2.2.4. 

There  are  two  asynchronous  traps  (AST)  which  the  retrieval  task 
is  required  to  implement- -one  to  handle  input  requests  from  the  VRS 
computer  via  the  communications  line,  and  one  to  handle  disk  read 
completions. 

The  AST  logic  required  for  handling  the  communications  line 
consists  of  linking  the  current  input  buffer  element  to  the  ’’in-use’' 
list  header  (Section  2. 4. 4. 1.1.1) ,  acquiring  the  next  available 
input  buffer  element  from  the  "available"  list  header,  resuming  the 
command  decoder,  and  issuing  a  communications  line  read  request.  In 
this  manner,  there  is  always  an  outstanding  read  request,  which 
ensures  that  no  requests  issued  by  the  VRS  computer  will  be  missed. 
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The  function  of  resuming  the  command  decoder  is  an  RSX-11D  operating 
system  directive  which  will  cause  the  command  decoder  to  re-start  if 
it  is  suspended  when  the  directive  is  issued,  or  will  not  cause  any 
action  if  the  command  decoder  is  not  suspended  when  the  directive  is 
issued. 

The  AST  logic  required  for  handling  disk  read  completions  is 
dependent  upon  the  original  reason  for  generating  the  read.  The 
final  function  of  the  disk  read  AST  logic  may  be  to  issue  another 
I/O  request,  either  another  disk  read  (which  will  cause  another  AST) 
or  a  communications  line  response  to  the  VRS  computer,  or  simply  to 
exit,  without  initiating  further  I/O  action. 

There  are  essentially  three  distinct  stages  during  a  briefing 
session  which  require  disk  access.  When  the  briefing  request 
message  #1  is  received,  it  is  necessary  to  verify  that  all  locations 
requested  exist  in  the  weather  data  base.  Each  identifier 
verification  read  completion  AST  will  start  the  read  for  the  next 
identifier,  until  the  final  identifier  is  verified.  The  final  AST 
will  cause  the  AST  logic  to  issue  a  message  to  the  VRS  computer. 

During  message  unit  delivery  in  response  to  VRS  computer 
demands,  the  disk  block  containing  the  message  unit  is  read,  when 
the  AST  occurs,  the  proper  message  unit  within  the  disk  block  must 
be  extracted  and  the  AST  logic  terminates  by  issuing  the  message 
unit  to  the  VRS  computer  via  the  communications  line. 


2.4.4. 1.4  PDP-11/70®  Retrieval  Task  Inputs  -  The  inputs  required 

for  the  retrieval  task  are  the  VRS  computer  command  messages  and  the 
processed  weather  data  base. 

The  briefing  request  messages  are  used  to  construct  channel 
dependent  directive  tables  and  parameters  which  become  secondary 
inputs  for  locating  the  required  weather  data.  The  tables  and 
parameters  are  discussed  in  Section  2. 4. 4. 1.1. 2. 
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The  demand  response  messages  are  used  to  retrieve  specific 
messaqe  units  from  the  weather  data  base  and  send  the  message  units 
to  the  VRS  computer.  The  message  units  may  be  recovered  and 
delivered  to  the  VRS  computer  either  in  sequence  (that  is,  in  the 
order  requested)  or  out  of  sequence  in  the  case  of  repeat  and  skip 
functions.  The  VRS  computer  controls  the  briefing  presentation 
order  by  demanding  which  message  unit  to  skip  ahead  from.  In 
addition,  demand  response  messages  are  used  to  indicate  channel 
activity,  such  as  end-briefing,  hang-up,  etc. 


2. 4. 4. 1.5  POP-11/70®  Retrieval  Task  OutDuts  -  The  primary  output  of 

the  retrieval  tasx  is  message  units  of  processed  weather.  The 
message  unit  information  is  transmitted  to  11/34  VRS  in  response  to 
the  11/34  demands. 

In  addition  to  the  primary  output  there  are  required  a  series  of 
secondary  outputs  which  are  constructed  as  a  function  of  compiling 
the  specific  briefing  requested. 

The  secondary  outputs  are  two  tables  which  are  channel  dependent 
and  reside  in  the  CSB.  They  are  the  channel  response  briefing  table 
(CRBT)  and  the  channel  response  message  unit  table  (CRMUT) . 

The  CR8T  is  an  ordered  list  of  weather  data  base  virtual  block 
numbers.  The  order  is  determined  by  compiling  the  list  in  the  same 
order  as  requested  by  the  VRS  computer.  That  is,  for  each  weather 
report  type  requested,  the  block  numbers  containing  the  weather  data 
are  written  to  the  table  in  location  identifier  order.  For  example, 
if  Hourly  Surface  Observations  (SA)  and  Terminal  Forecasts  (FT)  were 
to  be  requested  for  Boston  (BOS),  Albany  (ALB)  and  Washington 
National  (DCA) ,  the  CRBT  would  consist  of  the  virtual  block  numbers 
of  the  weather  data  base,  containing,  in  order,  the  BOS  5A,  the  ALB 
SA,  the  OCA  SA,  the  BOS  FT,  the  ALB  FT,  and  the  OCA  FT. 
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Corresponding  to  each  block  number  is  a  "flag"  word  containing 
flag  bits  for  new  report  type,  skip  type,  and  report  location  in  the 
Location  Index  Table.  As  the  briefing  message  units  are  demanded  by 
the  VRS  computer,  the  block  message  units  are  sequenced.  The 
sequence  number  of  the  first  message  unit  of  each  block  is  entered 
into  the  corresponding  message  unit  number  (MtJ#)  of  the  CRBT  as  the 
block  is  read.  This  number  is  also  entered  into  the  CRMUT  as  the 
least  message  unit  (LMG) .  The  sum  of  this  number  and  the  number  of 
message  units  contained  in  the  block  is  the  greatest  message  unit 

(GMG) .  When  a  message  unit  is  demanded  that  is  greater  than  the 

current  GMG,  the  next  block  of  the  briefing  is  read.  If  a  message 
unit  is  demanded  that  is  less  than  the  LMG,  the  appropriate  block  is 
found  by  the  previous  MG#. 

Figure  2-20  shows  the  construction  process  for  the  CRBT  and 
CRMGT.  The  blocks  are  listed  in  briefing  order  with  their 
appropriate  "flag"  values.  For  example,  block  256  contains  the  BOS 
SA  weather  data.  The  flag  values  are: 

Bit  1  •»  1  BOS  is  the  first  SA  report 

Bit  2  »  1  SA  skip  protocol  -  skip  to  next  report  type 

Last  4  bits  ■*  1  SA  is  the  first  report  in  the  Location 

index  Table- 

In  this  example,  block  466  has  been  read  into  the  buffer.  Its 
first  message  unit  is  the  eighth  message  unit  of  the  briefing. 

Since  block  466  contains  three  message  units,  the  eighth  through 
tenth  message  unit  is  currently  in  the  buffer.  This  is  indicated  by 
the  CRMGT  values. 

In  addition  to  the  outputs  required  to  satisfy  the  briefing 
(message  units  and  briefing  tables)  ,  an  Error  and  Diagnostic  File  is 
generated.  This  file  maintains  a  history  of  activity  of  the 
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retrieval  task.  Additional  outputs  of  the  retrieval  task  could  be 
accounting  information  files  allowing  an  analysis  of  system  resource 
use. 

2. 4. 4. 1.5.1  Message  On it  Transmission  Format  -  The  message  units 
are  transmitted  according  to  a  fixed  communications  protocol 
(Appendix  B) .  The  message  units  are  buffered  directly  from  the 
channel  status  block  area  into  which  they  are  read  from  disk 
(OTOA) .  That  is,  the  address  presented  to  the  DV-11  handler  is  the 
one  representing  the  correct  message  unit  position  of  the  block  of 
data  residing  in  the  CSB. 

2. 4. 4. 2  Winds  Aloft  Retrieval  -  When  a  briefing  request  for  Winds 
Aloft  data  is  received  by  Retrieval,  it,  in  turn,  must  request  the 
data  from  a  special,  installed  task.  Winds  Aloft  Retrieval 
(FDRTRV) .  This  is  because  Winds  Aloft  information  must  be 
dynamically  interpolated  for  each  location  from  a  grid  of  winds  data 
stored  in  the  DDF  (see  Section  2. 4. 3. 2. 4). 

FDRTRV  receives  and  processes  requests  for  winds  Aloft 
information  for  a  given  location,  altitude,  and  time  period. 
Restrictions  on  the  input  to  the  program  are  that  the  altitude 
cannot  be  greater  than  45,900  feet  and  the  time  period  cannot  be 
more  than  30  hours  beyond  the  effective  date  and  time  of  the  winds 
aloft  data.  Blocks  numbers  returned  by  FDRTRV  contain  message  unit 
data  for  the  given  altitude,  an  altitude  4,000  feet  higher,  and  an 
altitude  4,000  feet  lower  (unless  the  given  altitude  was  equal  to  or 
less  than  6,000  feet,  in  which  case  an  altitude  2,000  feet  lower  is 
given) .  If  the  altitude  given  is  determined  to  be  less  than  the 
estimated  terrain  height  for  the  location  given,  then  the  values 
returned  are  for  an  altitude  equal  to  the  terrain  height  plus  2,000 
feet  and  a  higher  altitude  equal  to  the  previous  value  plus  2,000 
feet  and  a  higher  altitude  equal  to  the  previous  altitude  value  plus 
'  4,000  feet.  If  the  altitude  given  plus  4,000  feet  is  greater  than 

\ 
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45,900  feet,  then  the  higher  altitude  values  are  not  returned  by 
FDRTRV .  Alternatively,  if  the  lower  altitude  calculated  for  the 
given  altitude  is  lower  than  the  terrain  height,  no  values  are 
returned  for  the  lower  altitude. 

The  values  which  are  returned  by  FDRTRV  for  each  altitude  are 
the  wind  direction  in  degrees,  the  wind  speed  in  knots  and  the 
temperature  in  whole  degrees  Celsius,  since  these  values  are 
determined  by  interpolation  from  retrieved  data  values,  if  critical 
data  are  missing  or  have  become  too  old,  (more  than  30  hours)  a 
message  of  "data  not  available”  is  returned. 

After  FDRTRV  has  calculated  the  Winds  Aloft  Data  and  stored  them 
in  message  units  in  the  DDF,  it  then  returns  the  block  numbers  to 
the  Retrieval  program.  These  block  numbers  are  inserted  into  the 
appropriate  Channel  Response  Briefing  Table  for  use  during  the 
weather  briefing. 
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3 .  SUPPORT  SOFTWARE 


In  addition  to  the  operating  sys terns ,  there  are  programs 
required  to  create  and  initialize  the  VRS  data  base. 


3.1  UDFPRG 

Using  a  file  (NLC.DAT)  containing  the  name,  region,  and 
geographic  coordinates  of  each  weather  reporting  station,  UDFPRG 
creates  the  file  UDF.DAT  where  VRS  processed  weather  reports  are 
stored  (see  Section  2. 3. 2. 2). 


3.2  ERRCRT 

When  raw  weather  reports  read  from  the  KCW.DAT  file  contain 
errors,  they  are  stored  by  VRS  in  an  error  file  (ERR. DAT)  where  they 
are  accessible  by  the  editor.  ERRCRT  creates  ERR. DAT  (see  Section 
2. 4. 3. 5) . 


3 . 3  DEPTT 

The  Data  Edit  Position  Terminal  Tasks,  in  conjunction  with 
DEPST,  constitute  the  editor  used  to  correct  erroneous  raw  weather 
reports  (see  Section  2. 4. 3. 5). 


3.4  VRINIT 


Before  VRS  can  be  executed,  certain  initialization  functions 
must  be  performed.  The  subroutine  VRSMAP  initializes  the  UDF  block 
allocation  map  by  flagging  all  table  blocks  as  being  in  use  and  the 
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remaining  report  blocks  as  being  £ree.  It  then  scans  the  Locator 
Index  Table  for  any  report  blocks  in  use  and  sets  the  corresponding 
map  bytes  in  the  UDF  block  to  one,  signalling  the  blocks  in  use. 

Also  if  there  are  any  duplicate  report  blocks  for  locations, 
signifying  an  error  has  occurred  in  block  allocation,  the  blocks  in 
question  are  zeroed  thus  preventing  invalid  reports  for  location. 

There  exists  a  file,  SFI.DAT,  which  is  used  by  the  VRS 
subroutine  VRPAOV  to  determine  if  any  new  reports  have  been  recently 
added  to  KCW.DAT.  SFI.DAT  contains  the  same  subfile  pointers  that 
are  contained  at  the  beginning  of  KCW.DAT  itself.  If  new  reports 
have  been  added,  the  data  will  not  be  the  same  and  VRS  then  knows  it 
must  invoke  the  report  processors.  The  VRINIT  subroutine,  VRSPTR, 
initializes  SFI.DAT  to  point  to  the  most  recent  set  of  weather 
reports  so  that  the  VRS  will  process  them  as  soon  as  execution  has 
begun. 

3 . 5  VRSTOP 

To  safely  stop  the  VRS  execution  in  a  coordinated  way  that 
insures  all  files  are  closed  and  an  I/O  function  is  not  interrupted 
before  completion,  VRSTOP  is  executed.  A  message  is  sent  to  the  VRS 
executive.  When  the  VRS  sees  it,  an  acknowledgment  is  sent  and  both 
the  VRS  and  the  VRSTOP  exit. 

3.6  NLCUPD 

The  file  NLC.DAT,  containing  identifying  information  on  each 
weather  reporting  station,  is  used  by  ODFPRG  to  create  the  DDF  (see 
Section  3.1).  NLC.DAT  is  built  and  modified  by  program  NLCUPD, 
which  provides  editing  capabilities. 


3.7  SENDIC 


The  "dictionary"  portion  of  the  11/34  vocabulary  disk  file, 
DIRECT. DVF,  is  needed  by  the  11/70  dictionary  task.  SENDIC  sends  it 
to  the  VRS  disk  area  on  the  11/70. 


3.8  WRDICT 

Once  SENDIC  (above)  has  been  executed,  the  file  created  at  the 
11/70  is  made  into  a  common  block  within  the  11/70  dictionary  task 
by  executing  this  utility. 
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4.  VRS  MAINTENANCE* -11/ 3 4 

For  discussion  of  the  11/34  maintenance  procedures  the  reader 
should  be  familiar  with  the  RT-11VD3  Extended  Memory  Monitor  and 
MACRO-11  programming.  The  reader  should  have  a  thorough 
understanding  of  the  functional  flow  of  completion  routines  before 
attempting  to  modify  the  11/34  software  (see  Reference  9) . 


4.1  PROGRAM  CREATION  PROCEDURE 

The  RT-11V0 3  indirect  command  file  capability  is  used  to  create 
the  11/34  VRS  software.  The  indirect  command  file  ASMVRS.COM 
assembles  the  software  from  the  MACRO  sources.  The  following 
modules  must  be  present  to  assemble  the  system: 

e  BACKGR.MAC 
e  DAP. MAC 

•  DICT.MAC 

•  SPEC. MAC 
e  SPEAK. MAC 

•  SEND. MAC 
e  CLOCK . MAC 
e  PURGE. MAC 

•  QfJEUE .  MAC 

•  TRAP. MAC 
e  TABLE. MAC 
e  TRAC .  MAC 

•  PREFIX. MAC. 

The  following  four  modules  must  be  present  to  generate  the 
specialized  data  handlers  for  insertion  into  the  RT-11  operating 
system: 
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•  A OX. MAC 

•  LCX-MAC 

•  LI  X.  MAC 


•  LOX.MAC.  . 


By  typing  ‘,@ASMVRS"  all  object  modules  listed  above  will  be 
generated.  The  object  modules  must  be  linked  together  to  create  the 
VRS  save  image  file.  The  command  file  VRSLNK  performs  this 
operation.  To  list  the  software  package,  the  users  can  type  @ASMLST 
and  the  sources  of  all  seventeen  modules  will  be  listed  on  the  line 
printer.  To  generate  the  specialised  handlers  needed  by  the 
software,  the  command  file  VRSHND  should  be  invoked. 

Figure  4-1  is  a  subroutine  tree  of  the  11/34  modules.  Since  the 
software  is  a  Macro-11  asynchronous  event-driven  program,  the  tree 
does  not  depict  logical  program  flow.  It  is  meant  to  depict 
possible  modular  interface.  See  Appendix  A  for  a  more  detailed 
description  of  the  modules. 


4.2  SYSTEM  REQUIREMENTS 

To  generate  a  twenty  channel  voice  response  system  the  following 
assumptions  are  made: 

•  Hardware 

a.  PDP-11  with  extended  memory  management 

b.  64K  words  16-bit  memory 

c.  Fast  Random  Access  Disk  with  a  capacity  of  at  leaat 
3.5  Megabytes 

d.  Specialized  DMA  ADPCM  Module 
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11/34  SOFTWARE  SUBROUTINE  TREE 

(continued) 
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e.  2  asynchronous  line  units 

£.  1  20-channel  Votrax  MC-I 

q.  1  TCD-100  Timing  Control  rjnit 

Software  - 

RT-11  VO 3  XM  generated  for  use  with  the  specified  disk. 
Data  Bases  - 


DIRECT. DVP  -  this  file  (5000  blocks  long)  contains  all 
utterances  spoken  by  the  system.  It  is  created  using 
the  ADPCM  encoder  and  programs  VEDIT  and  RECORD  (see 
Reference  6,  Chapter  8). 


VRDATA.DAT  -  this  file  (1000  blocks  long)  is  created 
by  the  VRS  software  and  contains  all  statistics  data 
generated  in  system  operations. 


r 

5.  VRS  MAINTENANCE— 11/70 

*  For  the  discussion  of  11/70  maintenance  procedures,  the  reader 

,  should  be  familiar  with  FORTRAN- IV  PLUS  and  MACRO-11  programming 

languages  under  the  RSX-llD  monitor  and  with  the  RSX-11D  utilities, 

,  special  subroutines,  overlay  capabilities,  event  flags,  priority 

levels,  and  asynchronous  system  traps. 

5.1  TASK  CREATION  CONVENTIONS 

The  RSX-llD  command  file  capability  is  used  to  assemble, 
compile,  taskbuild,  and  install  or  remove  most  tasks.  The  command 
files  are  named  AAABBB.CMD,  where  AAA  is  the  task  name  abbreviation 
(e.g.,  VRS)  and  BBB  is  LST  if  a  compiling  command  file,  INS  if  an 
installing  command  file  and  REM  if  a  removing  command  file.  BBB  is 
omitted  if  the  command  file  is  for  taskbuilding.  For  example,  if  a 
task  were  to  be  built  from  the  FORTRAN-  source  file  VRS.FTN,  the 

* 

procedures  would  be  as  follows: 

•  o  MCR  F4P  @VRSLST  -  to  compile,  then 

o  MCR  TKB  @VRS  -  to  taskbuild. 

If  VRS.CMD  used  the  TKB  overlay  switch  an  overlay  definition 
file  must  exist  and  would  be  named  VRS.ODL. 

The  command  files  are  written  to  create  object  files  the  same 
name  as  the  source  file  and  to  create  nonspooled  compiler  listings 
on  disk. 

.  5.2  SOFTWARE  CONVENTIONS 

t  The  following  items  are  miscellaneous  practices  in  the  11/70  VRS 

software.  The  11/70  program  written  in  MACRO-11  are  DICT,  RETREV, 
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VRSTIM,  and  VRSGLB.  These  programs  require  the  special  capabilities 
available  only  with  MACRO-11,  such  as  the  asynchronous  system 
traps.  The  rest  were  written  in  FORTRAN-IV  PLUS:  VRINIT,  VRS, 
VRSOUT,  VRSFO,  FDRTRV,  VRSTOP,  (JDFPRG,  and  ERRCRT. 

Many  of  the  subroutines  of  the  FORTRAN  programs  reference  by 
means  of  an  INCLUDE  statement  the  file  VRPARAM.FTN  which  contains 
ubiquitous  VRS  parameters  in  common.  The  parameters  are: 

•  TTI  -  Terminal  logical  unit  number 

•  LPU  -  Line  printer  logical  unit  number 

•  LOTERR  -  ERR. DAT  logical  unit  number 

•  LUNKCW  -  KCW.DAT  logical  unit  number 

•  luntjdf  -  UDF.DAT  logical  unit  number 

•  LUNHIS  -  SFT.OAT  logical  unit  number 

•  MAXIN  -  Raw  weather  report  buffer  size  (from  ROW. DAT) 

•  MAXOUT  -  Processed  weather  buffer  size  (to  UDF.DAT) 

•  ISLOTS  -  Location  Index  Table  size  in  blocks 

•  IESTEDT  -  EST  or  EDT  time  indicator  - 

The  VRS  software  makes  use  of  the  RSX-llD  special  subroutines  to 
handle  inter-task  communications.  A  variable  number  of  parameters 
pertinent  to  the  transaction  are  transmitted  using  VSNDRR  and 
responses  received  using  VRECRR. 

All  disk  files  are  referenced  within  the  software  as  residing  on 
disk  structure  DB7 .  An  assignment  can  be  made  with  the  RSX-llD 
monitor  that  would  define  DB7  as  being  any  other  single  disk 
structure . 

Task  priorities  are  fine-tuned  through  experience  with  the 
system,  but  in  general  it  can  be  said  that  the  device  handlers  must 
run  under  the  highest  priority  used  and  that  RETREV  and  FORT REV  must 
run  at  a  higher  priority  than  the  VRS  processor  to  insure  good 
response  time. 


5-2 


5.3  SUPPORT  SOFTWARE  TASK  CREATION 


The  programs  used  to  create  and  initialize  data  base  files  and 
perform  other  auxiliary  functions  are  discussed  in  Section  3.0. 

This  section  will  discuss  how  to  create  the  executable  file  for  each. 


5.3.1  UDFPRG 

The  Universal  Data  File,  UDF.DAT,  is  created  with  UDFPRG  which 
requires  as  input  the  file  NLC.DAT  containing  the  identifying  data 
for  each  weather  reporting  station  and  airport.  UDFPRG  is  comprised 
of  five  source  files:  UDFPRG,  BLCR8 ,  IOBLCK,  VRSLIB,  and  NOMESG. 
They  are  compiled  and  listed  using  the  command  file  UDFLST.CMD  and 
taskbuilt  using  UDFPRG.CMD. 


5.3.2  ERRCRT 


Raw  weather  reports  containing  format  errors  are  sent  to  the 
file  ERR. DAT  which  is  created  using  program  ERRCRT.  ERRCRT  is 
contained  on  a  single  source  file,  ERRCRT. FTN,  and  so  compile 
command  file  is  used.  The  compiler  command  line  is  as  follows: 

•  MCR  F4P  ERRCRT,  ERRCRT  1-SP  *  ERRCRT. 

•  For  taskbuilding,  the  command  file  ERRCRT.CMD  is  used. 


5.3.3  VRSGLB 

A  VRS  global  common  area  is  created  with  VRSGLB.  The  source 
file,  VRSGLB. MAC,  is  assembled  using  the  MACRO  Command  File 
GLBLST.CMD.  Taskbuilding  is  accomplished  when  the  DICT  module  is 
taskbuilt  with  DICT.CMD. 


5.3.4  VRINIT 


SFI.DAT  is  a  file  containing  the  KCW.DAT  pointers  existing  at 
the  time  VRS  last  processed  the  raw  weather,  reports,  when  SFI.DAT 
and  the  RCW  pointers  no  longer  match,  VRS  knows  new  reports  have 
been  entered.  SFI.DAT  is  created  or  initialized  by  a  subroutine  of 
VRINIT,  VRSPTR.  VRINIT  also  initializes  the  map  array  in  the  GCA. 

VRTNIT  is  comprised  of  6  source  files:  VRINIT,  VRSMAP,  ZOLUTIM, 
OTELAP,  EXTHED,  and  VRSLIB.  They  are  compiled  using  VRINLST.CMD  and 
taskbuilt  using  VRTNTT.CMD. 


5.3.5  VRSTOP 

The  only  safe  way  to  stop  the  11/70  VRS  executive  is  to  run 
VRSTOP,  which  insures  that  the  DDF  block  usage  control  array  will  be 
in  order.  Any  other  method  such  as  ABORT  or  a  system  crash  will 
require  running  VRINIT  before  execution  could  be  resumed.  The  F4P 
command  lines  needed  to  compile  the  VRSTOP  modules  are  as  follows: 

•  MCR  F4P  VRSTOP'* VRSTOP 

•  MCR  F4P  VRSLIB* VRSLIB 

The  TKB  command  file,  VRSTOP.CMD  is  used  for  taskbuilding. 


5.3.6  NLCOPD 


An  editor  is  required  to  modify  and  add  to  NLC.DAT,  the  file 
containing  the  weather  reporting  station  identification  data. 
NLCVPO  is  compiled  as  follows: 

MCR  F4P  NLCVPD*NLCVPD. 

Taskbuilding  is  done  with  TKB  command  file  NLC.CMD. 
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5.4  VRS  WEATHER  PROCESSOR 


The  VRS  Processor  executive  is  an  overlaid  task  with  the  tree 
structure  shown  in  Figure  5-1.  The  VRS  root  contains  the  only 
MACRO-11  routine  for  the  task,  VRSTIM.MAC.  The  second  level  of 
overlays  constitute  the  primary  VRS  functions: 

e  OPEND  opens  and  closes  files  and  check  subfile  pointers  for 
KCW.DAT,  SFT.DAT,  and  ERR. DAT. 

e  SA  is  the  surface  observations  processor. 

e  SARMK  is  the  surface  observations  remarks  processor. 

•  ft  is  the  Terminal  Forecast  processor. 

•  ERR  is  the  erroneous  report  handler. 

The  names  given  are  those  used  in  the  overlay  Definition  Files. 

Five  other  tasks  also  called  by  the  VRS  processor  executive, 
differ  from  the  above  in  that  they  are  independently  executing 
programs,  not  just  subroutines  of  VREXEC. 

1.  VRSFD  is  the  Winds  Aloft  processor.  The  compiler  command 
lines  are  as  follows: 

•  MCR  F4P  VRSFD-VRSFD 
e  MCR  F4P  VRSLIB*VRSLIB. 

Taskbuilding  and  installation  are  accomplished  with  the  command 
files  VRSFD.CMD  and  FRSINS.CMD,  respectively. 

2.  VRSOOT,  the  VRS  I/O  task,  is  comprised  of  eight  source 

*  modules  which  are  compiled  by  means  of  the  F4P  command  file 
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VKSOUT 


VRSLST.CMD.  Taskbuilding  is  done  with  VRSOfJT.CMD  and  the  overlay 
definition  file  VRSO0T.ODL.  Installation  is  done  with  VRSINS.CMD. 

i  3.  DTCT,  the  module  that  translates  raw  weather  reports  to 

dictionary  pointers,  is  comprised  of  the  two  modules  DICT. MAC  and 
VOCAB.MAC  (Plus  assembly  contents  contained  on  PREFIX. MAC)  which  as 
assembled  with  the  following  MACRO  command  lines: 

•  MCR  MAC  DICT  *  PREFIX,  DICT 

•  MCR  MAC  V0CA8  *  PREFIX,  V0CA8. 

Taskbuilding  is  done  with  TKB  command  file  DTCT.CMO  and  installation 
with  FRSTNS.MO. 

4.  RETREV,  the  VRS  weather  data  retrieval  program,  is  comprised 
of  10  MACRO  source  files  which  are  assembled  with  MACRO  command  file 
RETASM.CMD.  To  taskbuild,  RETREV.CMD  is  used.  See  Figure  5-2. 

5.  FDRTREV ,  which  calculates  Winds  Aloft  data,  consists  of  5 

.  source  files  compiled  with  F4P  command  file  FDRLST.CMD. 

-  Taskbuilding  is  done  with  FDRTRV.CMD.  Installation  is  done  with 

.  VRSINS.CMD.  See  Figure  5-3. 

5.5  PERIODIC  SOFTWARE  CHANGES 

The  PDP-11/70®  system  time  is  set  to  Eastern  Standard  or  Eastern 
Daylight  Time.  VRS,  however,  runs  under  Greenwich  Mean  Time  and 
three  routines  must  be  changed  biannually:  RETVER. MAC ,  a  subroutine 
of  RETREV,  DTELAP.FTN,  and  ZtJLfJTM.  MAC ,  subroutines  of  VRSOUT.  The 
chancres  to  the  FORTRAN  programs  DTELAP,  and  ZfJLDTM  may  be  made  to  a 
change  to  include  parameter  IESTEDT. 

t 

r 
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RET  INI - SUSPEN 


QUEUE 
DQUEUE 
GETCSB 
BRF2  *~ 


CMDND 


FDBLK 

SEND 

SENDMU 

QUEUE 

GETCSB 

DBLOCK 

■SENDMU 


OUTPUT 

OUTSND 


TINAST 


GETCSB 

DQUEUE 

QUEUE 

SUSPEN 

ERRTN 


MKAST - RCVAST - 1 - SEND 

1 - GETCSB 


RDAST 


ASTVER 

■ASTSKP 

ASTDMD 


■SENDMU 

DEMAND 


SNDAST - SUSPEN 

RCVAST - 1 - SEND 

1 - GETCSB 


t 


FIGURE  5-2:  RETREV  Subroutine  Tree 
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FDRTRV 


RECEV  - 
SUMMIT 
ACT  IV  - 


■  VRECSP 
ERRPRC 

IOBLCK 

WTFOR3 

VSNDRR 
EXIT 
RECEV  ■ 


•R50ASC 

■IDATE 

TIME 

IOBLCK 

BLCR8 

VRECEX 


VRECSP 

ERRPRC 


VRSFD - 1 - RECEV - - - VRECSP 

j  - - ERRPRC 

; - GTRPT - 1 - BLOCK 

!  - - ALTSTR 

- - EXTSTR 

• - IDATE 

- - IOBLCK 


FIGURE  5-3 


FDRTRV  And  VRSFD  Subroutine  Tree 


6.  OPERATIONS  MANUAL 


The  following  is  a  summary  of. steps  required  to  start  up 
and  shut  down  the  VRS  system: 

•  Start  Up  11/70  Subsystem 

a.  Log  On  Terminal 

b.  Bring  Up  Subsystem 

•  Start  Up  11/34  Subsystem 

a.  Power  Up  System 

b.  Boot  11/34 

c.  Bring  up  Subsystems 

•  "Abort  RETREV"  Line  Clean  Up 
e  Shut  down  11/70  Subsystem 

e  Shut  down  11/34  Subsystem 
e  "Barge  In"  On 
e  "Barge  In"  off 

•  System  Test. 

Details  of  these  procedures  are  given  next  in  this 
section.  If  there  is  a  problem,  refer  to  Figure  6-1  which 
outlines  in  flow-chart  form  procedures  for  handling  problems. 


6.1  START  UP  11/70  SUBSYSTEM 


6.1.1  Log-on  Terminal 

Enter  on  the  Terminal: 

CTRL/2 

CTRL/C 

MCR  HEL  1300 ,100]  (CR) 
PASSWORD  (password) (CRl 


START  SYSTEM 
TROUBLE  CHECKOUT 
HERE 
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VRS  System  Trouble  Chart  (Cont 


bring  down 
11/34  SUBSYSTEM 


FIGURE  6-1:  VS S  System  Trouble  Chart  (Cont'd.) 


© 


FIGURE  6-1:  VRS  System  Trouble  Chart 


(Cont'd.) 


6,1.2  Bring  Up  Subsystem 


6. 1.2.1  Initial  Procedure 

MCR  RUM  DB7: VRINTT(ESC] 

INITIALIZE  VRS  -  START  HH;MM;SS  EST 
CALLING  VRSMAP 
CALLING  VRSPTR 

INITIALIZATION  COMPLETE:  HH:MM:SS  EST 
CTRL/C 

MCR  RUN  DB7 : VRS [ ESC ] 

DD-MMM-YY  7RXEC  HAS  RESTARTED  HH:MM:SS  EST 

AT  1  HH : MM: SS  EST 

etc. 


6. 1.2.2  Recovery  Procedure 

MCR  RUN  DB7: RECOVER (ESC] 

RECOVER  VRS  -  START;  HH:MM:SS  EST 
CALLING  VRSMAP 

VRS  RECOVER  COMPLETE;  HH:MM;SS  EST 

CTRL/C 

MCR  RUN  DB7 : VRS [ESC]  etc. 


,  * 

:  ! 
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6.1.3  Start  Op  11/34  Subsystem 


6. 1.3.1  Power  rjp  system 

a)  11/34  Computer 
Switch  to  DC  ON 

b)  Teleterm 

Set  switches:  LOCAL  #0-,  ON 


c)  Opper  two  VOTRAX  units 
Switch  ON. 


6. 1.3. 2  Boot  11/34 


6. 1.3. 2.1.  From  Fixed  Head  Disk 

Depress  panel  buttons:  CTRL/HALT,  CTRL/BOOT 
Should  print  4  octal  numbers  on  terminal) 

SL  177462  [CR] 

SD  177400  [CR] 

$L  177460  [CR] 

$D  5  [CR] 

$L  0  [CR] 

$S[CR] 

. RT-11XMV03 -02 
.INS  MC,AD,LI,LO 


t 


1 


.D  56*2012 
lDATE  OD-MMM-YY(CR] 
/TIME  HH:MM:SS(CR] 
lDATE[CR) 

.TIME  [CR] 


(GMT) 

(Verification) 

(Verification) 


6. 1.3. 2. 2  From  CDC  Backup  Disk 

Oepress  panel  buttons:  CTRL/HALR,  CTRL/BOOTSL  1000 (CRl 
(Should  print  4  octal  numbers  on  terminal) 

$L  1000  [CR] 

SD  12700 [CR) 

$D  176712  [CR] 

SD  12760 [CR] 

SD  1  [CR] 

SD  12  [CR] 

SD  105760 [CR] 

SD  12  [CR] 

SD  100375 [CR] 

SD  5040  [CR] 

SD  5040  [CR] 

SD  5040  [CR] 

SD  12740  [CR] 

SD  400  [CRl 
SD  12740  [CR] 

SD  5  [CR] 

SD  105710  [CR] 

SD  100376 [CR] 

SO  5007  [CR] 

$L  1000 [CR] 

$S  [CR] 

.RT-11XMV03 

.INS  MC,RF,AD,LI ,LO 
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.TIME  HH: MM: SS[CR]  (GMT) 

.  DATE  (CR)  (Verification) 

.TIME  [CR]  Verification). 


6. 1.3. 3  Bring  rjp  Subsystem 


6. 1.3. 3.1  Initial  Procedure 


^  DEL  VRDAT A . OAT ( C  R] 

PILES  DELETED  : 

DK: VRDATA.DAT  ?  Y[CR] 

^R  VRS  [CR] 

VRS  VERSION -03X -00 

(If  the  remaining  print  out  does  not  appear  as  listed 
below,  enter  "EXIT[CR] "  on  the  11/34  terminal  and  try 
"R  VRS [CR] -  again. ) 

MCR 

MCR  HEL  [300,100] 

PASSWORD  * 

MCR  RtJN  RETREV  $ 

INITIALIZATION  COMPLETE 

(At  this  point,  do  a  "SYS"  command  on  the  11/70 
terminal  anc  check  that  "RETREV"  is  running.) 


6. 1.3. 3. 2  Recovery  Procedure 

Same  as  above  (i.e.,  Section  6. 1.2. 3.1)  except  do  not 
delete  VRDATA.DAT  file. 


r 


6. 1.3. 4  Console  Commands 

There  are  six  console  commands  available  to  the 
operator  which  affect  the  operation  of  VRS  on  a 
particular  channel.  The  commands  are  typed  on  the  VRS 
console  in  the  following  format: 

.CnnX  cr  where 

nn  is  the  two  digit  channel  specifier  (single 
digit  channels  must  be  preceded  by  a  zero)  and  X 
is  the  command  letter  identifier  as  listed  below. 

6. 1.3. 4.1  CnnN 

The  command  turns  off  the  trace  function  on  the 
channel  nn. 

6 . 1 . 3 . 4 . 2  CnnT 

This  command  allows  the  trace  functions  to  be 
performed  for  the  channel  nn. 


6. 1.3. 4. 3  CnnD 

This  command  disables  the  channel  nn;  that  is,  no 
calls  will  be  received  on  that  line. 


6. 1.3. 4. 4  CnnR 

This  command  re-enables  the  channel  nn;  that  is,  a 
channel  that  has  been  disabled  will  now  be  able  to 
receive  calls. 
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6. 1.3. 4. 5 


CnnX 


This  conunand  de-activates  the  fifteen-minute  time-out 

0 

on  the  line  nn. 

£ 

m 

6 . 1 . 3 . 4 . 6  CnnA  j 

This  command  activates  the  fifteen-minute  time-out  on 
the  line  nn. 


6.1.4  Shut  Down  11/70  Subsystem 

Type  the  following  in  the  11/70  terminal: 

CRTL/Z 

CRTL/C 

MCR  RUH  VRSTOP [ESC] 

»***VRS  EXEC  TERMINATING 
VRS--STQP 

(NOTE:  It  may  take  up  to  5  minutes  to  obtain  the  last 

line.) 


6.1.5  Shut  Down  11/34  Subsystem 


6. 1.5.1  Temporary  Procedure 

Enter  the  following  on  the  11/34  terminal: 
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(All  the  channel  lights  should  go  out.) 


6.1.5. 2  Final  Procedure 
_EXIT[CR] 

^COPY  VRDATA.DAT  DP:TRmmdd.yyV[CR] 
jdir  *.yyv(CR) 

^DEL  VRDATA . DAT ( CR] 

FILES  DELETED: 

DK: VRDATA. DAT  ?  Y[CR] 

The  intention  is  to  save  the  trace  file  on  the  CDC  disk 
under  the  file  name  TRnundd.yyV  where  "mm"  is  the  number  of  the 
month,  "dd"  is  the  day  of  the  month,  and  "yyn  is  the  year.  It 
is  suggested  that  these  trace  files  be  periodically  archived  to 
magnetic  tape. 


6.1.6  "Barge  In"  On 

1.  Set  switch  on  "barge  in"  phone  to  activate  the  message 
of  interest,  i.e.,  either  the  "temporary  down"  or  "overnight" 
message . 


2.  Switch  on  the  "barge  in"  to  activate  the  "barge  in" 
unit. 


3.  Call  8-202-347-3222  to  check  the  "barge  in"  message. 


6.1.7  "Barge  In"  Off 


1.  Switch  off  "barge  in". 

2.  Call  8-202-347-3222  to  check  on  system  response. 


0 


0 


4 

6.1.8  System  Test 

1.  Call  into  system  on  a  local  line. 

2.  Enter  "DCA"  loc  ID  and  check  out  all  the  weather 
products. 


6.1.9  System  Trouble  Chart 

The  intention  of  this  section  is  to  direct  the  operator  to 
the  appropriate  action  that  should  be  taken  for  various  system 
malfunctions. 


# 
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7.  USERS*  MANUAL 


Any  public,  business,  or  home  telephone  with  a  12-key 
signalling  system  can  be  used  to  access  the  system.  The 
conventional  rotary  dial  telephone  may  be  used  only  for  dialing 
the  access  numbers,  however,  an  acoustically-coupled  tone 
signalling  device  (in  lieu  of  a  Touch-Tone®  telephone)  can  be 
employed  in  conjunction  with  the  rotary  dial  telephone  to  enter 
the  information  requests. 


7.1  ENTERING  DATA 


To  communicate  with  the  computer  you  must  use  the  keypad  in 
a  way  that  the  computer  "under stands . "  Locations  (weather 
reporting  stations  and  airports)  are  uniquely  identified  by 
three-letter  combinations  and  you  enter  these  three -letter 
identifiers  to  delineate  a  single  location  or  a  series  of 
locations  (e.g.,  a  proposed  flightpath)  for  which  you  desire  to 
know  the  weather. 

The  keypad  does  not  have  enough  keys  to  allow  the  entry  of 
an  alphabetic  character  (latter)  with  a  single  keystroke.  But 
it  is  possible  to  make  an  unambiguous  entry  by  depressing  two 
keys.  You  can  enter  a  particular  letter  by  depressing  the  key 
on  which  that  letter  appears  and  another  key  to  indicate  which 
of  the  three  letters,  1st,  2nd,  or  3rd.  The  numeral  "l"  key 
indicates  the  1st  letter,  the  numeral  "2"  key  indicates  the  2nd 
and  the  numeral  "S"  key  indicates  the  3rd.  Thus  the  letter  B 
is  signalled  by  depressing  the  key  on  which  B  appears  (the 
number  "2'*  key)  and  then  the  numeral  "2"  key  (2nd  letter  in  the 
group,  ABC) .  The  letter  C  is  signalled  by  depressing  the  key 
on  which  "C"  appears  and  the  numeral  "3"  key  (3rd  letter  in 
group  ABC).  Eor  example,  DCA  is  entered  as  D-l,  C-3,  A-l,  as 
shown  below. 


As  shown  above,  the  letters  Q  and  Z  and  the  blank  character 
are  assigned  to  the  numeral  "l"  key.  Q  is  1-1,  "Blank"  is  1-2 
and  Z  is  1-3.  Bach  of  the  twenty-six  letters  of,  the  alphabet 
can  be  entered  in  this  fashion  (two  keystrokes)  and  no 
confusion  will  result.  The  'blank*  is  not  used. 

NOTB:  In  addition  to  the  1-  2-  3-  keys  for  second 

keystroke  denoting  the  letter  position,  left-middle-right  keys 
of  the  same  row  may  also  be  used  for  a  faster  keystroke.  For 
example,  the  letter  'S'  is  contained  on  key  seven  as  shown. 


The  user  may  use  the  keystrokes  7-9  to  denote  'S'  since  'S' 
is  on  key  seven  in  the  right  position  thus  7-9  may  be  used 
instead  of  7-3.  However,  the  left,  middle,  or  tight  second 
keystroke  must  be  in  the  same  row. 

It  does  not  suffice  just  to  be  able  to  communicate  a  string 
of  letters  of  the  alphabet  to  the  computer.  You  must  be  able 
to  tell  the  computer  what  you  want  done  with  the  information 
you  have  provided.  At  the  lower  right-hand  corner  of  the 
keypad,  there  is  a  key  imprinted  with  a  "t”  symbol,  we  call 
this  the  'computer  entry'  key  or,  for  conciseness,  the  'pound' 
key.  Since  this  key  is  not  used  to  transmit  letters  or 
numbers,  it  creates  no  confusion  to  employ  it  as  a  control  key 
to  signal  an  action  or  a  request.  Used  in  conjunction  with 
other  keys,  a  number  of  different  actions  can  be  signalled. 
Other  control  functions  will  be  explained  later. 

Some  location  identifiers  use  both  letter  and  numerals. 

For  these  entries,  it  is  necessary  to  use  two  keystrokes  for 
each  letter  or  numeral.  The  context  of  the  pilot-computer 
dialogue  will  often  preclude  ambiguities  and  permit  simpler 
data  entry.  Numbers  can  be  entered  unambiguously  by  depressing 
the  'OPER'  key  and  the  appropriate  numeral  key.  The  'OPER'  key 
is  the  key  representing  the  numeral  '0'  (or  zero)  so  that  entry 
of  the  numeral  'O'  involves  two  actuations  of  the  'OPER'  key. 
The  numeral  '5'  is  communicated  by  depressing  'OPER'  and  '5' 

(as  shown  below)  and  the  other  numerals  are  similarly 
communicated. 


■  h  a  ! 

5 

B  63  H 

h  h  a 

HUB 

i  H  B 

H  H  H 

El  m.  El 

EL  H  a, 

_ _ 

•  Wrong  Identifier  -  If  a  three-character  entry  which  does 
not  constitute  a  valid  location  identifier  is  made 
(e.g.,  ABC),  the  VRS  will  read  back  the  characters  as 
entered.  However,  when  the  report  requested  is  to  be 
read  out,  the  VRS  will  say  " ALPHA-BRA VO-CHARLIE. . .  is 
not  a  location  identifier." 

•  Mo  Report  for  a  Given  Location  -  If  the  location 
identifier  is  a  valid  one  but  not  a  reporting  station 
for  the  type  of  report  requested,  the  VRS  will  say 
"ALPHA-8RAVO-CHARLIE . . .  is  not  an  Hourly  Observation 
Station"  or  "...  is  not  a  Terminal  Forecast  location." 

•  Moncurrent  Data  -  If  the  location  identifier  is  a  valid 
one  but  the  current  data  are  not  available,  the  VRS  will 
say  (e.g.,  SBY) ,  "SIERRA-BRA VO- YAMREE. . .  report  not 
available"  for  report  type  requested. 

MOTE:  •  Hourly  Observations:  Only  the  latest 

available  observation  will  be  given  provided 
that  the  observation  is  not  more  than  2  hours 
old.  Soecial  observations  will  be  appended  to 
last  hourly. 

•  In  this  system  all  reporting  stations  for 
weather  observations  within  the  continental 
United  States  are  contained  in  the  data  base. 

•  Minimum  altitude  for  forecasted  winds  Aloft  is 
approximately  2,000  feet  above  terrain  level. 

•  The  system  has  some  time-out  functions  which 
limit  the  amount  of  time  an  individual  can  use 
the  system.  This  feature  has  been 
incorporated  to  preclude  an  individual  from 
tying  up  the  phone  lines  for  an  extended 
period. 


The  computer  must  be  able  to  recognize  the  end  of  an  entry 
(i.e.,  a  string  of  alphabetic,  numeric  or  mixed  characters)  and 
the  request  that  it  respond.  The  computer  entry  key  ('#'  key) 

’  is  depressed  twice  to  provide  the  end-of-entry  signal 

i  immediately  following  each  and  every  field.  Thus,  to  request 

weather  data  for  Martinsburg,  W.  Va.  (and  vicinity)  the 
keystroke  sequence  'M-l',  'R-2',  'B-2',  '#'•#'  is  generated  . 

% 

The  computer  will  'read  back'  each  item  entered  so  that  the 
correctness  of  the  entry  may  be  verified  .  The  phonetic 
alphabet  will  generally  be  used  so  that  the  identifier  MIV  will 
be  read  back  as  "MIKE"  "INDIA"  "VICTOR";  CHO  will  be  read  back 
as  "CHARLIE"  "HOTEL"  "OSCAR".  For  some  locations,  the  actual 
name  of  the  airport  will  be  read  back.  For  example,  DCA 
(Washington  National  Airport)  will  be  read  back  as  "Washington 
National. " 


7.3  CONTROL  FUNCTIONS 

The  use  of  the  key  was  discussed  previously  in  section 
7.2.  The  (STAR)  key  is  used  to  stop  the  computer 

response,  while  in  the  response  mode,  if  it  is  necessary  to 
interrupt  the  computer  voice  response,  depress  the  key. 

This  will  halt  the  voice  response  until  the  operator  is  ready 
to  proceed.  The  operator  may  then  order  a  resumption  of  voice 
response,  a  repeat,  a  jump  ahead  (skip)  or  a  begin  over,  by 
selecting  the  appropriate  keystroke  sequence  shown  below. 

Notice  that  the  enter  command  is  not  required  after  the 

control  functions  containing  the  '*'  (STAR)  keystroke. 

ENTER _ #  #  REPEAT _ *  7 

YES _ 9  #  #  JUMP  AHEAD _ *  5 
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PILOT 


Y;  #  » 


SYSTEM  -  reads  forecasts  for  PIT  and  ILG 

SYSTEM  -  "Do  you  want  winds  aloft  forecasts?  Answer  yes 
or  no." 

PILOT  -  Y;  #  #  ;/ 

SYSTEM  -  "How  many  hours  from  now?  The  maximum  is 
30  hours. 

PILOT  -  6;  •  # 

SYSTEM  -  ’•six’* 

SYSTEM  -  "At  what  altitude?" 

PILOT  -  85;  (or  8500;  no  matter)  #  # 

SYSTEM  -  "eight  five" 

SYSTEM  -  reads  winds  aloft  at  requested  altitude, 

+4000  feet  and  -4000  feet  for  each  location. 

SYSTEM  -  "Do  you  need  more  information?  Answer  yes  or  no. 

PILOT  -  Y;  #  # 

SYSTEM  -  "Enter  location  identifier,  etc." 
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11/34® 


MODULE  NAME; 


ADX. SYS 


PROGRAM? 

SOURCE  PILE: 

PURPOSE; 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 

COMMON; 

SUBROUTINES  CALLED; 

FUNCTION  DESCRIPTION; 


COMMENTS; 


11/34  VRS 
ADX.MAC 

ADPCM  output  device  driver  for  20  channels 


Called  by  a  WRITE  request  in  speak  module 
QUEUE.  QUEUE  pointers  are  arranged  by  a  trap 
call  which  executes  some  code  in  trap  handler, 
then  jumps  to  subroutine  in  handler  which 
links  QUEUE  pointers, 

ADCQE 

ADLQE 


DQUEUE  -  DE-QUEUE  an  element 
OPF  -  take  element  off  ADX  QUEUE  list 
EQUEUE -  QUEUES  an  element 
PUT  -  put  element  onto  ADX  QUEUE  list 
SETRPT  -  turn  on  interrupts 

Output:  Upon  -  WRITE  request: 

1.  DEQUEUES  FROM  RT-11  QUEUE 

2.  QUEUES  internally  one-QUEUE  per  channel 

3.  Initiates  NPR  output 

On  completion  of  ADPCM  write: 

1.  DEQUEUES  from  internal  QUEUE 

2.  Transfers  element  back  to  RT-11  QUEUE 

3.  Requests  write  completion  on  ADPCM. 

This  driver  handles  data  synchonously  for  each 
user  by  maintaining  a  separate  output  queue 
for  each  user.  When  a  write  request  is 
issued,  the  element  is  removed  (unlinked)  from 
the  RT-11  queue  and  held  until  completion  of 
the  write  (speech) ,  when  it  gets  re-linked  to 
RE-11  queue.  Therefore,  RT-11  never  sees  more 
than  1  write  on  the  channel  at  any  point  in 
time. 


MODULE  NAME 


LIX.SYS 


PROGRAM; 

SOURCE  PILE: 

PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 

COMMON: 

SUBROUTINES  CALLED: 

FUNCTION  DESCRIPTION: 

COMMENTS: 


11/34  VRS 
L I X . MAC 

Input  driver  for  communication  between  11/70 
and  11/34  by  serial  line 


Called  by  . READC  in  background  routine  during 
INIT 

Called  by  .READC  in  send/receive  when 
communicating 

LICQE: 

LILQE: 

SINPTR 

Monitor  CUR's 

SPUTBYT 

Input:  Receives  characters  from  11/70  and 

stores  them  in  user  buffer  space  associated 
with  channel  to  which  data  applies.  <CR>  is 
treated  as  an  end-of-file. 

At  initialization  time,  a  series  of  10  .READC 
requests  are  issued  for  synchronization. 
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MODULE  NAME: 


LOX . SYS 


PROGRAM: 

SOURCE  FILE: 

PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 

COMMON: 

SUBROUTINES  CALLED: 

FUNCTION  DESCRIPTION: 

COMMENTS: 


11/34  VRS 
LOX. MAC 

SLU  device  driver  for  output  side  of  11/34  to 
11/70  communication 


Called  by  WRITE  in  BACKGROUND  module 
Called  by  WRITE  in  SEND/RECEIVE  module 

LOLQE 

LOCQE 

SINPTR 

RT-11  System  Functions 

SGTBYT 

Output:  Functions  like  a  DL-11 
Receives  characters  from  user  buffer  or  text 
string.  Transfers  one  character  at  a  time 
under  interrupt  control  at  priority  4. 

This  driver  treats  <CR>as  an  end-of-file. 
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MODULE  NAME: 

MCX.SYS 

PROGRAM: 

11/34  VRS 

SOURCE  FILE: 

MCX.MAC 

PURPOSE: 

Touch-Tone®  input  handler  for  20  channels 

CALLING  ROUTINES  AND 

CALLING  SEQUENCE: 

Output  -  Called  by  .WRITE  in  background.  This 
occurs  in  response  to  reception  of 
STATUS  CHARS  from  data  set. 

Input  -  Enabled  by  setting  interrupt  enable 
bit  (BIS  #100,  @#175630)  after 
initialization  in  background  routine 

COMMON: 

MCICQE 

MCILQE 

MCOCQE 

MCOLQE 

SUBROUTINES  CALLED: 

DEFUSB  -  Define  user  status  block 

LVMCON  -  input  character  decoder 

SIGNAL  -  signal  significant  event 

FUNCTION  DESCRIPTION: 

Input: 

1.  Accept  chars  from  VOTRAX  unit,  check  for 
and  remove  SYNC  CHAR,  separate  control 

CHARS  from  data  CHARS,  if  data  numeric, 
check  for  legality  of  numeric  data. 

Convert  2  numbers  into  a  letter.  If 
control  or  status  CHAR,  signal  the  event, 
if  just  data,  stash  in  channel  buffer 

Output: 

2.  Produces  line  status  changes  (answer, 
hang-up,  disconnect) 

COMMENTS: 

MCX  never  issues  READ  completions  to  RT-11. 
Instead,  it  writes  the  data  word  directly  into 
the  user  buffer,  then  gives  a  completion 
signal  to  the  background.  Causes  interrupt 
whenever  a  digit  is  received. 

COMMENTS: 


MODULE  MAMS: 

PROGRAM: 

SOURCE  PILE: 

PURPOSE: 

CALLING  ROUTINES: 

CALLING  SEQUENCE: 
COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 


INITIALIZATION  ROUTINES 
11/34  VRS 
BACRGR. MAC 

To  allocate  memory  set  up  I/O  QUEUES 

This  is  first  routine  in  VRS.  entered  thru 
start  address  START.  This  code  is  executed 
once  only. 


All  TR. ***  Parameters  defined  by  PREFIX. MAC 
US.*** 

SP.*** 

FL. *** 

DP.*** 

None 

1.  Allocates  extra  QUEUE  elements. 

2.  Allocates  space  in  extended  memory  for 
dictionary. 

3.  Allocates  space  in  extended  memory  for 
buffers. 

4.  Oefines  extra  I/O  channels. 

5.  Prints  version  ID. 

6.  Creates  USB's  one  per  line. 

Then  continues  to  dictionary  initialization 


COMMENTS 


MODULE  NAME; 


DICTIONARY  INITIALIZATION 


PROGRAM: 

SOURCE  PILE: 
PURPOSE: 

CALLING  ROUTINES: 

CALLING  SEQUENCE: 
COMMON: 

SUBROUTINES  CALLED: 


FUNCTION  DESCRIPTION: 


COMMENTS: 


VRS 

BACKGR.MAC 

To  open  channels,  read  in  dictionary  and 
assure  proper  communication  with  11/70 

Entry  point  JFA001 

Code  is  executed  once  only. 


User  Status  block  parameters 

DICT 

STRTIM 

TRAP  TR.QUE 
TR.DQE 
TR. USB 

1.  Opens. TTy  handler, 

2.  Opens  one  file  per  channel  for  dictionary 
reads. 

3.  Reads  dictionary  directory  blocks  into  core. 

4.  Starts  VRS  clock  by  loading  RT-11  time. 

5.  Assigns  I/O  channel  numbers  to  ADPCM. 
devices,  Touch-Tone®  receiver ,  11/70  input, 
and  11/70  output. 

6.  Logs  into  11/70  RSX  system  and  runs  RETREV. 

7.  Prints  initialization  complete  message. 

8.  Jumps  to  BACKGR  to  await  significant  events. 

During  11/70  log  on,  all  messages  from  11/70 
are  echoed  on  TTY. 
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MODULE  NAME; 

PROGRAM; 

SOURCE  FILE; 

PURPOSE; 

CALLING  ROUT I WES; 

CALL I MG  SEQUENCE: 
COMMON: 

SUBROUTINES  CALLED: 

FUNCTION  DESCRIPTION: 


COMMENTS: 


BACKGR 

VRS 

BACKGR. MAC 

Polling  loop  to  check  for  significant  events 

Program  returns  to  this  module  at  completion 
of  any  function. 

JMP  BACKGR 

Parameters  defined  by  PREFIX. MAC 

TRAP  TR.SIG 
TRAP  TR.USB 

1.  Checks  BTTMSK  and  BITMSK+®  FOR  DEVICES 
COMPLETIONS.  If  no  completions,  continues 
checking . 

2.  When  completion  occurs,  determines  which 
channel  it  was. 

3.  Uses  channel  #  to  determine  USB  address. 

4.  Jumps  to  proper  completion  routine  by 
vectoring  from  DONVEC  table. 

Also  prints  appropriate  error  messages  upon 
detection  of  errors 
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MODULE  NAME 


DISABL 


PROGRAM; 

SOURCE  PILE: 

PURPOSE; 

CALLING  ROUTINES; 
CALLING  SEQUENCE; 

COMMON; 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 


11/34  VRS 
B  AC  KG  R.  MAC 
Disables  a  channel 
DAP 

Rl  — ►  channel  # 

RO  - ►  USB  ADDR 

JSR  PC,  DISABL 


None 

1.  Pushes  RO  onto  the  stack. 

2.  Puts  channel  #  into  .WRITE  parameter  block 
DISADW. 

3.  Does  a  .WRITE  to  MCX  which  puts  selected 
channel  out  of  service. 

4.  Restores  RO  and  returns  via  RTS  PC. 


COMMENTS 


MOOULE  NAME 


ENABLE 


PROGRAM: 

SOURCE  FILE: 

PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 
COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 


COMMENTS: 


11/34  VRS 
BACKGR.MAC 

Enables  Datasets  in  use  by  system. 
D I SCON 


None 

1.  Pushes  RO  onto  the  stack. 

2.  Clears  the  line  timeout  flag. 

3.  Puts  channel  number  into  .WRITE  parameter 
block  ENABDW. 

4.  Does  a  .WRITE  to  M CX,  which  enables  one 
channel. 

5.  Restores  RO  and  returns  via  RTS  PC. 
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MODULE  NAME; 
PROGRAM: 

SOURCE  PILE: 
PURPOSE; 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 
COMMON: 

SUBROUTINES  CALLED: 


FUNCTION  DESCRIPTION: 


COMMENTS : 


NXTCAR 

11/34 

BACKGR . MAC 

Routine  decodes  console  commands  of  the  format 
C  NN  X  where  NN  is  a  2-digit  channel  number. 

X  is  one  of  the  following:  N,  T,  D,  R,  A,  X 

This  is  a  read  completion  routine  from  TT. 


TR.VSB 

TTPAR 

TRAP  TR. USB 
PROCN 
PROCT 
PROCD 
PROCR 
PROCA 
PROCX 
PROCCR 
PROCLF 

1.  Pushes  R2 ,  R3 ,  R4 ,  and  R5  onto  the  stack. 

2.  Cheeky  for  exit  command  if  so,  restores 
registers  and  exits  to  nxtext, 

3.  Checks  for  legal  channel  number.  If  OK, 
resolves  USB  address;  if  error,  prints 
message  and  exits  to  NXTEXT. 

4.  Checks  for  legal  character  from  list  at 
CARCK.  Ignores  character  if  not  valid. 

5.  If  valid  character,  vectors  to  proper 
servicing  routine.  All  service  routines 
exit  thru  NXTEXT. 
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MODULE  NAME 


NXTEXT 


PROGRAM: 

11/34  VRS. 

SOURCE  FILE: 

BACKGR. MAC 

PURPOSE: 

Exit  routine  for 

NXTCAR 

CALLING  ROUTINES: 

NXTCAR 

PROCN 

PROCT 

PROCD 

PROCR 

PROCA 

PROCX 

PROCLF 

CALLING  SEQUENCE: 

JMP  NXTEXT 

COMMON: 

NXTBUF 

SUBROUTINES  CALLED: 

None 

FUNCTION  DESCRIPTION:  1.  issues  another  .READC  to  TT: 

2.  Restores  saved  registers. 

3.  Exits  from  completion  via  RTS  PC 


COMMENTS 


MODULE  NAME 


PROCA 


PROGRAM:  11/34  VRS. 

SOURCE  PILE:  BACKGR.MAC 

PURPOSE:  Turns  on  line  timeout  for  channel  specified  if 

not  already  on. 

CALLING  ROUTINES:  NXTCAR 

CALLING  SEQUENCE:  JMP  @  VCT-2  (Rl) 

COMMON; 

SUBROUTINES  CALLED:  None 

FUNCTION  DESCRIPTION:  1.  Sets  timeout  bit  in  USB. 

2.  If  user  on  that  line,  starts  a  raarktirae. 

3.  Exits  to  NXTEXT. 


COMMENTS 


MODULE  NAME 


PROCCR 


PROGRAM:  11/34  VRS. 

SOURCE  FILS:  BACKGR.MAC 

PURPOSE:  Treats  <CR>  -as  a  valid  character/  but  ignores 

t  it. 

CALLING  ROUTINES:  NXTCAR 

► 

CALLING  SEQUENCE:  JMP  @  VECT-2  MM) 

COMMON: 

SUBROUTINES  CALLED:  None 

FUNCTION  DESCRIPTION:  1.  Returns  immediately  to  NXTEXT. 

COMMENTS: 


t 
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MODULE  NAME 


PROCD 


PROGRAM: 

SOURCE  PILE: 

PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 
COMMON: 

SUBROUTINES  CALLED: 

FUNCTION  DESCRIPTION: 

COMMENTS: 


11/34  VRS. 

SACKGR. MAC 

M 

Disconnects  "user  of  channel  specified  and 
disables  line.  I 

NXTCAR 

4 

JMP  3VECT-2  (Rl)  15 


COMMON 

TRESET 

SIGNAL 

1.  Causes  a  hard  hang-up. 

2.  Clears  the  USB. 

3.  Resets  the  Touch-Tone®  line. 

4.  Signals  the  event  via  BITMSK. 

5.  Exits  to  NXTEXT. 


\ 


1 


4 
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MODULE  NAME 


PROCLF 


PROGRAM: 
SOURCE  FILE: 
PURPOSE: 


11/34  VRS 
BACKGR. MAC 

Treats  <LF>-as  a  valid  character  but  ignores 
it. 


CALLING  ROUTINES: 
CALLING  SEQUENCE: 
COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 
COMMENTS: 


NXTCAR 

JMP  @  VECT-2  (Rl) 


None 

1.  Returns  immediately  to  NXTEXT . 


t 


« 


9 
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MODrjLB  NAME: 


PROCN 


PROGRAM: 

SOURCE  PILE: 
PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 
COMMON: 


11/34  VRS. 

BACKGR. MAC 

Turns  off  trace  for  channel  specified. 
NXTCAR 

JMP  §  VECT-2  (Rl) 

All  PL.***  as  defined  in  PREFIX. MAC 

rjs.  *** 


SUBROUTINES  CALLED:  MTCLOS 


FUNCTION  DESCRIPTION: 


1.  Turns  off  trace. 

2.  Closes  trace  statistics  file. 

3.  Exit  thru  NXTEXT. 


COMMENTS: 
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MODULE  NAME 


PROCR 


PROGRAM: 

SOURCE  FILE: 

PURPOSE: 

CALL I MG  ROUTINES: 
CALLING  SEQUENCE: 
COMMON: 

SUBROUTINES  CALLED: 

FUNCTION  DESCRIPTION: 


11/34  VRS. 

BACKGR.MAC 

Resets  and  enables  data  set  foe  channel 
specified. 

NXTCAR 

JMP  @  VECT-2  (Rl) 


COMMON 

TRESET 

ENABLE 

1.  Initializes  the  buffets. 

2.  Puts  a  hang-up  indicator  in  status  field. 

3.  Resets  channel. 

4.  Enables  the  line. 

5.  Exits  to  NXTEXT. 


COMMENTS 


MODULE  NAME 


PROCT 


PROGRAM: 

SOURCE  PILE: 

PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 
COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 


11/34  VRS. 

BACKGR. MAC 

Turns  on  trace  for  specified  channel 
NXTCAR 

JMP  9  VECT-2  (Rl) 

All  PL.***  as  defined  in  PREFIX. MAC 

US.*** 

OPNTR 

1.  Sets  trace  but. 

2.  Opens  trace  file. 

3.  Exits  to  NXTEX . 


COMMENTS 


MODULE  NAME 


PROCX 


PROGRAM; 

SOURCE  PILE: 

PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 
COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 


11/34  VRS. 

BACKGR. MAC 

Turns  off  line  timeout  for  channel  specified 
NXTCAR 

JMP  @  VECT-2  (Rl) 


None 

1.  If  timeout  is  already  disabled,  exits 
immediately. 

ELSE: 

2.  If  timeout  is  not  disabled,  timeout  by 
setting  a  bit  in  USB.  If  channel  in  use, 
cancels  marktime  and  exits  else  exits 
immediately. 


COMMENTS 


MODULE  NAME: 

PROGRAM: 

SOURCE  PILE: 

PURPOSE: 

CALLING  ROUTINES: 

CALLING  SEQUENCE : 
COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 


SIGNAL 
11/34  VRS 
BACRGR. MAC 

Given  channel  number,  seta  appropriate  bit  in 
BITMSR  or  BITMSR+2. 

PROCD 

MRRTIM  TIMOUU 
SP.DIS  MCX.SYS 

JSR  PC,  SIGNAL 

US.CHN 

None 

1.  Pushes  Rl,  R2,  R3  onto  the  stack. 

2.  Shifts  a  1  into  Rl  and  R2  the  same  number 
of  places  as  the  channel  number. 

3.  Puts  Rl  into  BITMSR+2  and  R2  into  BITMSR 
via  BIS  instruction. 

4.  Restores  Rl,  R2,  R3 ,  and  returns. 


COMMENTS 


MODULE  NAME 


STRTIM 


PROGRAM: 

SOURCE  PILE: 

PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 
COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  OESCRI PTION : 


11/34  VRS 
BACKGR.MAC 
Starts  VRS  clock 
DICTIONARY  INIT. 

JSR  PC/  STRTIM 

TIME,  TIME  +2 

SMLI  (Multiply  Routine) 

1.  Gets  GMT  from  TCU-100. 

2.  Converts  to  seconds  since  midnight. 

3.  Stores  2-word  result  in  TIME  and  TIME+2. 

4.  issues  a  1-second  marktime  so  next  event 
occurs  as  a  completion  routine. 


COMMENTS: 


MODULE  NAME 


TRESET 


PROGRAM:  11/34  VRS 

SOURCE  PILE:  BACKGR.MAC 

PURPOSE:  Unconditionally  resets  all  Touch-Tone®  lines. 

CALLING  ROUTINES:  DISCON  PROCD  PROCR  SP.DIS 

CALLING  SEQUENCE:  JSR  PC,  TRESET 

COMMON: 

SUBROUTINES  CALLED:  None 

FUNCTION  DESCRIPTION:  1.  Pushes  RO  onto  the  stack. 

2.  Puts  channel  number  into  write  parameter 
block  TRESDW. 

3.  Does  a  .WRITE  to  MCX  which  resets  all 
channels. 

4.  Restores  RO ,  then  returns  via  RTS  PC. 


COMMENTS 


MODULE  NAME 


CANCEL 


PROGRAM: 

SOURCE  FILE: 

PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 
COMMON: 

SUBROUTINES  CALLED: 

FUNCTION  DESCRIPTION: 


COMMENTS: 


11/34  VRS 
DAP. MAC 

Deletes  last  Touch-Tone®  input  in  response  to 
user  command  *3 

BACKGR 


TRAP  TR. MOD 

SPEAR 

CLRTTK 

1.  Ignores  command  if  user  in  briefing  mode  or 
being  disconnected. 

2.  Removes  one  locid  from  list  if  in  entry  mode. 

3.  Deletes  response  if  yes/no. 

4.  Speaks  "RE-ENTER''  to  user. 

5.  Returns, 
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MODULE  NAME; 
PROGRAM; 
SOURCE  PILE; 
PURPOSE: 


CLRTTK 

11/34  VRS.SAV 
DAP. MAC 

Enables  Touch-Tone®  key-ins  for  specified 
channel. 


CALLING  ROUTINES:  CANCEL  RPTSRP 

x  MVAL  K  g  K  I  p 


CALLING  SEQUENCE; 
COMMON: 


SUBROUTINES  CALLED; 
FUNCTION  SEXCRI PTION: 

COMMENTS: 


None 

1.  Enables  Touch-Tone 
appropriate  bits  in 

2.  Exits  via  RTS  PC. 


inputs  by  setting 
USB  flag  word  (US.FLG). 


a 


! 


* 
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MODULE  NAME 


COMMON 


PROGRAM; 

SOURCE  PILE: 

PURPOSE: 

CALLING  ROUTINES; 
CALLING  SEQUENCE; 
COMMON; 

SUBROUTINES  CALLED: 

FUNCTION  DESCRIPTION: 


11/34  VRS 
DAP. MAC 

Initializers  USB  for  new  user 
RING 

JSR  PC,  COMMON 


ECHDON 
TRAP  TR.QUE 

1.  Checks  if  ECHO  buffer  is  in  use. 

2.  Queues  an  element  onto  RDQUE. 

3.  Initializes  USB  PARAMETERS. 


COMMENTS: 


I 

t 

t 

a 

i  • 
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MOOrJLE  NAME: 


DAP 


PROGRAM:  11/34  VRS.SAV 

SOURCE  PILE:  DAP. MAC 

PURPOSE:  Dialogue  prompt  speaking  routine. 

CALLING  ROUTINES:  DAPCOM,  BACKGR 

CALLING  SEQUENCE: 

COMMON: 

SUBROUTINES  CALLED:  SPEAK 

All  SP.***  special  functions,  using  routine 
specified  in  TABLE  (VECTOR) 

FUNCTION  DESCRIPTION:  1.  Gets  pointer  to  next  protocol  field. 

2.  Executes  special  function  before  prompt  is 
specified. 

3.  Speaks  prompt. 

4.  Jumps  to  DAP  if  cycle  request  else  to 
BACKGR. 


COMMENTS: 


MODULE  NAME: 


DAPCOM 


PROGRAM: 

SOURCE  PILE? 
PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 
COMMON: 

SUBROUTINES  CALLED: 


11/34  VRS 
DAP. MAC 

Dialogue  protocol  cycling  routine 
BACKGR  ,  DAP 


SYNTAX 

ECHO 

All  SP.***  via  dialogue  TABLE  pointers,  at 
vector 


FUNCTION  DESCRIPTION: 


1.  Gets  cycle  pointer  from  USB- 

2.  Performs  special  function  if  any  in  table 
before  SYNCHK- 

3.  Performs  syntax  check: 

4.  Performs  special  function  before  echo  if 
entry  in  table. 

5.  Echos  response  if  required, 

6.  Performs  special  function  before  branching 
if  entry  in  table 

7.  Gets  pointer  to  next  dialogue  table- 
depending  on  yes,  no  or  normal  response. 

8.  Continues  to  DAP. 


COMMENTS: 


I 


\ 

\ 

« 
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MODPLE  NAME; 


DECRM 


PROGRAM: 

SOURCE  FILE: 

PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 
COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 

COMMENTS: 


11/34  VRS.SAV 
DAP. MAC 

Decrements  message  unit  number  during  repeat 
and  recycle. 

RPTSKP 


None 

1.  Adds  USB  BASE  ADDRESS  TO  OFFSET  IN  RS« 

2.  Decrements  message  unit  number. 

3.  If  resulting  message  unit  number  is  less 
than  0,  repleces  that  with  9. 


<• 
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MODULE  NAME 


DISCON 


PROGRAM: 

SOURCE  PILE: 
PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 
COMMON: 


11/34  VRS.SAV 
DAP. MAC 

Disconnects  .user  at  end  of  briefing 
BRIEPR 


SUBROUTINES  CALLED: 


ECHDON 

MRfCTIM 

BLDBRF 

SEND 


RTNQTJE 

CHKREQ 

TRESET 

ENABLE 


COMMON 

RPTREQ 

RBPDEC 

TR.MOO 

TR.QUE 


FUNCTION  DESCRIPTION:  1.  Cancels  channel's  TIMEOUT  marktime. 

2.  Interrupts  speech  in  progress. 

3.  Returns  ECHO  buffers. 

4.  Returns  QUEUE  elements. 

5.  Informs  11/70  of  disconect. 

6.  Performs  disconnect. 

7.  If  not  a  console  disconnect  (see  section 
6. 1.3. 4),  enables  line. 

8.  Exits  to  BACKGR. 


COMMENTS 


MODULE  NAME: 


ECHO 


PROGRAM: 

SQfJRCE  FILE: 

PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 
COMMON: 

SUBROUTINES  CALLED: 

FUNCTION  DESCRIPTION: 


COMMENTS: 


11/34  VRS.SAV 
DAP. MAC 

Echoes  usee  response 
DAPCOM 

JSR  PC,  ECHO 

PREFIX. MAC  defined  parameters 

TRAP  TR.DQE 

DICT 

SPEAR 

1.  Resolves  input  string. 

2.  Dequeues  an  element  from  ROQUE. 

3.  ADDS  before  phrase  for  short  delay 

checks  for  phonetic  echo. 

4.  Translates  phrase  by  call  to  DICT. 

5.  Busy's  out  echo  buffer. 

6.  Speaks. 

Exits  via  RTS* 
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MOOULE  NAME: 


ECHDON 


PROGRAM: 

SOURCE  PILE: 

PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 
COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 


COMMENTS: 


11/34  VRS 

DAP. MAC 

Returns  dynamic  buffers  used  in  echo  function 

COMMON 

JSR  PC/  ECHDON 

PREFIX. MAC  defined  parameters 

TRAP  TR.QUE 

1.  If  in  briefing  mode  echo  done  flag  is 
cleared,  then  QUEUE  ELEMENT  AT  US.SPK  is 
returned  to  RDQUE. 

2.  If  in  correction  mode,  correction  flag  is 
cleared,  then  QUEUE  element  at  US.  RCV  is 
returned  to  RDQUB. 

3.  Return  via  RTS  PC. 
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MODULE  NAME: 

PROGRAM: 

SOURCE  FILE: 

PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 
COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 


GO 

11/34  VRS.SAV 
DAP. MAC 

Resumes  briefing  in  response  to  user  command  *4 
BACKGR 


TRAP  TR.MOD 

1.  Take  a  Trace. 

2.  Resume  speech  only  if  interrupted  by  stop 
command. 

3.  Exit  to  BACKGR* 


COMMENTS 


MODULE  NAME 


INVALK 


PROGRAM: 

SOURCE  FILE: 

PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 
COMMON: 

SUBROUTINES  CALLED: 

FUNCTION  DESCRIPTION: 


11/34  VR S 
DAP. MAC 

Handles  invalid  keystroke  entries 

BACKGR 


TRAP  TR.  MOD 

SPEAK 

CLRTTK 

1.  Puts  invalid  keystroke  flag  in  status  word 
of  USB. 

2.  Resets  input  buffer/. 

3.  Speaks  message  "invalid  entry". 

4.  Enables  more  Touch-Tone®  inputs. 

5.  Exits  to  BACKGR. 


COMMENTS 


MODULE  NAME 


MORSPK 


PROGRAM; 

SOURCE  PILE: 
PURPOSE; 

CALLING  ROUTINES: 
CALLING  SEQUENCE; 
COMMON: 

SUBROUTINES  CALLEO: 


11/34  VRS.SAV 
DAP. MAC 

Checks  if  more  inputs  to  speak 
MRKTIM 


TRAP  TR.  USB 

READ 

TYRANT 


FUNCTION  DESCRIPTION:  1.  saves  R2 ,  R3 ,  R4 ,  and  R5  on  stack- 

2.  Gets  USB  address. 

3.  If  more  inputs 

READS  inputs  to  double  buffers 

Restores  registers 

Exits  completion  routine 

If  no  move  inputs,  it  exits  to  Backgr. 


COMMENTS: 

■■  ■  -  ■■  ■  • 


# 


A-36 


MODULE  NAME 


MRRCOM 


PROGRAM:  11/34  VRS 

SOURCE  PILE:  DAP. MAC 

PURPOSE:  Marktime  completion  routine  for  MRRTIM 

CALLING  ROUTINES:  Entered  at  completion  of  marktime  request 

issued  by  MRRTIM  routine 

CALLING  SEQUENCE: 

COMMON: 

SUBROUTINES  CALLED:  SIGNAL 

FUNCTION  DESCRIPTION:  1.  REsolves  USB  address. 

2.  Sets  up  RETRVN  FLAG  IN  VS.FLG  of  USB. 

3.  Signals  event  by  JSR  PC,  signal. 

4.  Returns  via  RTS  PC. 


COMMENTS 


MODrjLS  NAME 


MRKTIM 


PROGRAM: 

SOURCE  PILE: 

PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 
COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 


COMMENTS: 


11/34  VRS 
DAP. MAC 

To  wait  an  interval  of  time  specified  by  R4 
D I SCON 


None 

1.  Pops  a  word  off  the  stack  to  save  in  USB 
for  return  address. 

2.  Stores  Rl  in  USB  save  area. 

3.  Gets  time  parameter  from  R4  and  issues  MRRT 
request. 

4.  Returns  to  polling  loop  (JMP  BACKGR) . 


t 
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MODULE  NAME; 

PROGRAM; 

SOURCE  PILE: 

PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 
COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 

COMMENTS: 


i 

* 


NO 

11/34  VRS 
DAP. MAC 

Sets  no  response  indication  in  USB  permanent 
flag  bits  and  line  status  word. 

This  occurs  as  a  result  of  user  answering  a 
yes/no  query  with  a  no. 

BACKGR 


None 

1  Sets  appropriate  bits  in  US.  PER  and  in  Rl. 

2.  Branches  to  CHUSB. 

3.  CHUSB  puts  Rl  into  US.STA  and  returns  to 
DAPCOM. 
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MODULE  NAME 


NORMAL 


PROGRAM; 

SOURCE  PILE: 

PURPOSE; 

CALLING  ROUTINES; 
CALLING  SEQUENCE; 
COMMON; 

SUBROUTINES  CALLED; 
FUNCTION  DESCRIPTION; 


11/34  VRS 
DAP. MAC 

Sets  normal  response  indication  in  USB 
BACKGR 


None 

1.  Sets  appropriate  bits  in  Rl. 

2.  Puts  Rl  into  VS.STA  and  returns  to  DAPCOM. 


COMMENTS 


MODULE  NAME: 

PROGRAM: 

SOURCE  PILE: 

PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 
COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  DESCRI PTION: 


PUTTR 

11/34  VRS.SAV 
DAP. MAC 

Clears  out  talk  required  list  (TRL) 
RING 


TRAP  TR.DQE 
TRAP  TR.QUE 

1.  Calculates  TRL  list  head  ADDR. 

2.  Dequeues  an  element. 

3.  Queues  element  onto  RDQUE. 

4.  Loops  until  no  elements  in  TRL/  then 
returns  to  BACRGR. 


COMMENTS: 


MODULE  NAME: 

PROGRAM: 

SOURCE  PILE: 

PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 
COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 


COMMENTS: 


RECXC 
11/34  VRS 
DAP. MAC 

In  briefing  node,  restarts  briefing  from 
beginning  in  prompt  mode,  restarts  from  "hello*' 

8ACKGR 


All  PL.***  as  defined  in  PREFIX. MAC 

OS. *** 

TR.  *** 

ST. *** 

TRAP  TR. MOD 

1.  Puts  beginning  of  protocal  indication  in 
line  status  field. 

2.  If  in  briefing  mode,  starts  at  beginning  of 
briefing  by  putting  message  unit  #00  in 
US.SPK  and  executing  the  repeat  function 

( JMP  REPEAT). 

3.  If  not  in  briefing  mode,  re-starts  the  * 

session  by  executing  the  disconnect  logic  . 

(8R  DISCON) . 


* 


* 
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MODULE  NAME: 

PROGRAM: 

SOURCE  FILE: 

PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 
COMMON: 

SUBROUTINES  CALLED: 

FUNCTION  DESCRIPTION: 

COMMENTS: 


REPEAT 
11/34  VRS 
DAP. MAC 

Repeats  last  message  unit 


RPTSKP 
TRAP  TR.MOD 

1.  Modifies  line  status  field  of  USB. 

2.  If  in  briefing  mode,  goes  to  RPTSKP.  If 
not,  waits  for  completion  of  speech  before 
repeating  last  prompt. 

3.  Exits  to  BACKGR 
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MOPOLE  NAME: 

PROGRAM: 

SOORCE  FILE: 

PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 
COMMON: 

SOB ROUTINES  CALLED: 

FUNCTION  DESCRIPTION: 


COMENTS: 


RING 
11/34 
DAP. MAC 

Ring  indication  routine  for  all  channels. 
8ACKGR 


COMMON  POTTR 

TR.MOD 

1.  Executes  common  setup  routines. 

2.  Sets  ring  indication  in  fJSB  via  tR. MOD. 

3.  Sets  up  line  timeout  if  not  disabled  (15 
min) . 

4.  Sets  briefing  mode  to  prompt. 

5.  Clears  out  TRL. 

6.  Exits  to  DAP. 
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MODULE  NAME 


PROGRAM: 

SQfJRCE  PILE: 
PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 
COMMON: 


RPTREQ  (Also  REPDBC) 

11/34  VRS.SAV 
OAP.MAC 

Returns  elements  to  ROQUE 
DISCON 


SUBROUTINES  CALLED:  TRAP  TR.QUE 

FUNCTION  DESCRIPTION:  1.  If  entered  thru  RPTREQ,  queues  one  element, 

address  of  which  is  in  R5,  to  RDQUB  and 
exits  to  BACRGR, 

2.  If  entered  thru  REPDEC,  queues  one  element, 
address  of  which  is  in  R4,  to  ROQUE  and 
exits  to  BACKGR* 

COMMENTS: 


I 

e 

I  t» 

\  - 
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» 


MODULE  NAME; 

PROGRAM: 

SOURCE  FILE: 

PURPOSE: 

CALLING  ROUTINES: 

CALLING  SEQUENCE: 

COMMON: 

SUBROUTINES  CALLED: 

FUNCTION  DESCRIPTION: 

COMMENTS: 


RPTSKP 
11/34  VRS 
DAP. MAC 

Routine  common  to  SKIP  and  REPEAT  commands  in 
briefing  mode  only 

REPEAT 

SKIP 

JMP  RPTSKP  or 
BR  RPTSKP 

All 


BLDBRF 
SEND 
RTNQUE 
CHKREQ 
CLRTTK 
INCREQ 

1.  If  briefing  done  flag  is  high,  ignores 
repeat  skip,  and  exits  to  GO  • 

2.  If  repeat  request,  backs  up  to  beginning  of 
message  unit  and  returns  to  BACKGR. 

3.  If  skip  request,  dumps  message  unit 
pointers,  returns  QUEUE  elements, 
re-enables  Touch-Tone®  inputs  and  exits  by 
JMP  BRIEFR. 


TR. ***  as  defined  in  PREFIX. MAC 

US.*** 

FL.*** 

TSTRCV 

SENDRT 

SPEAK 

TR.QUE 


1 


r 


6 


MODULE  NAME 


RTNQUE 


PROGRAM: 

SOURCE  PILE: 

PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 
COMMON: 

SUBROUTINES  CALLED: 

FUNCTION  DESCRIPTION: 

COMMENTS: 


11/34  VRS 
DAP. MAC 

Dequeues  all-  QUEUE  elements  from  speak  QUEUE 
and  returns  them  to  reads  QUEUE 

RPTSRP  DISCON  TOGO 

JSR  PC,  RTNQUE 

All  TR.***  defined  in  PREFIX. MAC 

US.*** 

SP.*** 

FL.*** 

DP.*** 


TRAP  TR.DQE 
TRAP  TR.QUE 

1.  Determine  speak  Q  address  from  USB  address. 

2.  Dequeues  an  element. 

3.  If  no  element,  exit. 

4.  Queues  the  element  to  RDQUE. 

5.  Go  back  to  step  1. 
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MODULE  NAME; 
PROGRAM: 
SOURCE  FTLR: 
PURPOSE: 


CALLING  ROUTINES: 
CALLING  SEQUENCE: 
COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 


SKIP 

11/34  VRS.SAV 
DAP. MAC 

coramand° *5 eXt  me3Sa^e  ulUt  **»  response  to  user 
8ACKGR 


CLRTTK 

RPTSKP 


GO 

TR.MOD 


COMMENTS: 


1.  Modifies  line  status  block. 

2*  n«tC,CS  if1user  is  in  briefing  mode.  If 

aAC«Gr^p"3!0UCh'Tone*  and  exlts  Co 

3'  “2nd!1  brIefi"9  is  do"»-  H  so  ignore 
4.  Jumps  to  RPTSKP  to  skip  report  being  spoken. 


MODULE  NAME 


STOP 


PROGRAM: 

SOURCE  PILE: 

PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 
COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 


11/34  VRS.SAV 
DAP. MAC 

Stops  briefing  in  response  to  user  command 
BACRGR 


TRAP  TR. MOD 

1.  Takes  a  trace. 

2.  Interrupts  speech  if  in  briefing  mode. 

3.  Exits  to  BACRGR' 


COMMENTS 


MODULE  NAME: 

PROGRAM: 

SOURCE  FILE: 

PURPOSE: 

CALLING  ROUTINES: 

CALLING  SEQUENCE : 
COMMON: 

SUBROUTINES  CALLED: 

FUNCTION  DESCRIPTION: 


TIMOUU 

11/34  VRS.SAV 
DAP. MAC 

Line  timeout  completion  routine 

RING  issues  a  . MRKT  which  calls  TIMOUU  upon 
completion 


TRAP  TR. USB 
SIGNAL 

1.  Determines  USB  addr  of  offending  channel* 

2.  Sets  exit  bit  in  USB- 

3.  Signals  event  to  BACKGR* 

4.  Returns  from  completion  routine* 


COMMENTS 


MODULE  NAME: 


TOGO 


PROGRAM: 

SOURCE  PILE: 
PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 
COMMON: 

SUBROUTINES  CALLED: 


FUNCTION  DESCRIPTION: 


COMMENTS: 


I 


11/34  VRS.SAV 
DAP. MAC 

Waits  for  end  of  current  message,  then  speaks 
timeout  message. 

BACKGR 


TRAP  TR.DQE 
TR.QUE 
MARKTIM 
RTNQUE 
PUTTR 
SPEAR 
SP.DIS 

1.  Turns  off  briefing  mode. 

2.  Waits  3  seconds. 

3.  Dequeues  any  talk  header  elements  and 
returns  them  to  free  element  pool. 

4.  Also  returns  user* 3  read  header  elements  to 
free  pool. 

5.  Returns  speak  Queue  elements. 

6.  Returns  TRL  Queue  elements. 

7.  Speaks  timeout  message. 

8.  waits  3  seconds. 

9.  Hangs  up  on  user. 

10.  Returns  to  polling  loop  (BACKGR). 
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MODULE  NAME 


YES 


PROGRAM: 

SOURCE  FILE: 

PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 
COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 

COMMENTS: 


11/34  VRS 
DAP. MAC 

Sets  YES  response  bits  in  permanent  flag  and 
line  status  words  of  USB 

BACKGR 


None 

1.  Sets  appropriate  bits  in  USPER  and  in  Rl. 

2.  Branches  to  CHUSB. 

3.  CHUSB  puts  Rl  into  VS.STA  and  returns  to 
DAPCOM . 


* 


1 
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MODULE  NAME: 

PROGRAM: 

SOURCE  FILE: 

PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 

COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION; 

COMMENTS: 


DICT-DICTST 
11/34  VRS 
VOCAB.MAC 

Translate  ASCII  text  into  VRS  code  pairs 

Dictionary  initialization  in  BACKGR.MAC  and 
ECHO  in  DAP. MAC 

Call  DICTST t  which  calls  DICT  as  a  mark time 
completion  routine 


SIGNAL 

1.  R2  --  Address  of  text  string  to  be 
translated. 

2.  R3  —  Address  of  word  pair 

1  word  -  byte  length  of  translation 

2  word  -  address  of  translation* 

DICTST  is  called  to  set  a  one  second  mark  time 
which  will  call  DICT  as  a  completion  routine. 


A- 5  3 


INPUT  OUTPUT  COMPUTER  SERVICES  INC  WALTHAM  MA 
TWENTY-CHANNEL  VOICE  RESPONSE  SYSTEM. (U) 

JUN  SI 


F/6  17> 

DOT-TSC-1313 


UNCLASSIFIED 


FAA-RO-01-51 


NL 


MODULE  NAME: 

PROGRAM: 

SOURCE  FILS: 

PURPOSE: 

CALLING  ROUTINES: 
CALLIN  SEQUENCE : 
COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 

COMMENTS: 


ALPHA 
11/34  VRS 
SPEC. MAC 

Check  input  buffer  characters  for  proper  locid 
syntax  -  alpha -numeric 

SYNTAX 


SYNFLG:  Flag  for  1st  character  check  -  then 
*/•  will  be  allowed 

VALID,  INVALA  (SYNTAX),  ANEX 

1.  Input:  R3  -  input  buffer  pointer. 

2.  Output:  C-Bit  set  for  invalid  format. 


«• 
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MODULE  wmE 


ASKYNO 


PROGRAM: 

SOURE  RILE: 

PURPOSE: 

CALLING  ROUTINES: 

CALLING  SEQUENCE: 
COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 

COMMENTS: 


VRS  (11/34) 
SPEC. MAC 


Sets  error  flag  if  last  response  not  yes. 


SP.FCT 

SP.FER 

SP.L08 


SP.NOT 

SP.PTR 

SP.PRP 


SP. SYR 


SP.SAS 


FL.YER 
UR. PER 

None 

1.  input:  RO  -  USB  address. 

2.  Output:  C-bit  set  for  error  return* 


The  return  address  is  popped  off  stack  if 
error,  that  is,  not  a  yes  response. 
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MODULE  NAME; 
PROGRAM; 

SOURCE  PILE: 
PURPOSE; 

CALLING  ROUTINES; 
CALLING  SEQUENCE; 
COMMON; 


SUBROUTINES  CALLED; 
FUNCTION  DESCRIPTION; 

COMMENTS; 


8RIEPR 
VRS  (11/34) 

SPEC. MAC 

Check  for  phone  hang  up;  if  so  jumps  to 
disconnect  logic.  If  not,  gets  next  protocol 
address  and  puts  the  return  address  on  stack* 

BACKGR 


* 


f 


t 


Prefix  parameters: 

FL.TRN 
US . PER 
US . DAP 
VECTOR 
US.SA1 
US . SA2 

01 SCON 

1.  input:  RO  -  USB  address. 

2.  Output:  R1  -  protocol  vector  address 

SP  -  saved  return  address. 


f 
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MODULE  NAME: 

PROGRAM: 

SOURCE  PILE: 

PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 
COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 

COMMENTS: 


CKHNUM 
11/34  VRS 
SPEC. MAC 

To  check  input  characters  are  numeric 
NUMINP 


NINVAL 

1.  Input:  R3  -  pointer  to  character  to  be 
checked. 

2.  Output:  Calls  'NINVAL'  if  character  not 
number. 
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MODULE  NAME; 

PROGRAM: 

SOURCE  PILE: 

PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 
COMMON; 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 
COMMENTS: 


NUMBER 
11/34  VRS 
SPEC. MAC 

* 

Count  number"  of  characters  process  and  check 
that  character  is  numeric  ? 

DAP 


k 


SYNFLG:  used  as  character  processed  flag 
NUMFLG:  count  of  characters  processed 

INVALN  (see  SYNTAX) 

Input:  R3  -  input  buffer  pointer. 


* 


s 
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MODULE  NAME 


CKHNUM 


PROGRAM: 

SOURCE  PILE: 

PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 
COMMON: 

SUBRUTINES  CALLED: 
FUNCTION  DESCRIPTION: 


11/34  VRS 
SPEC. MAC 

To  chock  Input  characters  are  numeric 

NUMINP 


NINVAL 

1.  Input:  R3  -  pointer  to  character  to  be 
checked, 

2.  Output:  Calls  'NINVAL*  if  character  not 
number. 


COMMENTS 


MODULE  NAME 


SP.  SSL 


PROGRAM;  VRS  (11/34) 

SOURCE  PILE:  SPEC. MAC 

PURPOSE:  Enter  channel  identifier,  and  briefing  mode 

into  buffer  and  initialize  location  flags  and 
counters 

CALLING  ROUTINES:  SP.LST 

COMMON:  fJS .  BEG  PL .  LST 

US.TRM  PL. PIR 

US . BRP 

US. CUR 

US. RCV 

US. PER 

SUBROUTINS  CALLED:  None 

FUNCTION  DESCRIPTION:  1.  Input:  RO  -  US 8  address* 

2.  Output:  Channel  identifier  and  briefing 

mode  entered  into  buffer 


COMMENTS 


SP. 8 RE 


MOOQLE  NAME; 


PROGRAM; 

SOORCE  PILE; 
PURPOSE; 

CALLING  ROOTINES: 
CALLING  SEQUENCE: 
COMMON; 

SOBRQOTNES  CALLED; 


VRS  (11/34) 

SPEC . MAC 

Moves  the  br-iefing 
DAP 

OS. BEG 
OS.IND 
OS.BRP 
OS. COR 

None 


mode  into  the  buffer 


PONCTION  DESCRIPTION;  1.  Input; 


2.  Output: 


RO  -  OSB  address 

OS. BEG  -  contains  beginning  point 
for  buffer 

OS.BRP  -  contains  briefing  mode, 
buffer  now  contains  briefing  mode» 


COMMENTS; 


SP.BRl 


r 


MODULE  NAME: 
PROGRAM: 
SOURCE  PILE: 
PURPOSE: 


CALLING  ROUTINES: 
CALLING  SEQUENCE: 
COMMON: 


VRS  (11/34) 
SPEC. MAC 


Check  briefing  mode  input  against  table  of 
valid  modes  ('Prompt,'  'Bnmode,'  'local')  and 
inputs  valid  mode  into  buffer 


DAP 


US.INP 
US. CUR 
US.8RF 


SUBROUTINES  CALLED:  INVALR,  SP.BRE 

FUNCTION  DESCRIPTION:  Input:  RO  USB  address- 
COMMENTS: 


MODULE  NAME: 

SP .CAR 

PROGRAM: 

VRS  (11/34) 

SOURCE  FILE: 

SPEC. MAC 

PURPOSE : 

1.  Calculates  number  of  characters  in  the 
input  buffer 

2.  Saves  the  return  addresses  in  the  USB  JMPS 
to  NSPLA  to  send  data 

CALLING  ROUTINES: 

SP.CSV 

SP .ETA 

SP.FTR 

SP.LST 

SP.WRN 

CALLING  SEQUENCE: 

COMMON: 

US. CUR 

US. BEG 

US.SA1 

US . SA2 

SUBROUTINES  CALLED: 

DISPLA 

FUNCTION  DESCRIPTION: 

COMMENTS: 

1.  Input:  RO  -  USB  address. 

2.  Output:  R4  -  number  of  characters. 
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MODULE  NAME 


SP.CLA 


PROGRAM: 

SOURCE  PILE; 

PURPOSE: 

CALLING  ROUTINES: 

CALLING  SEQUENCE: 
COMMON: 

SUBRQfJTINES  CALLED: 
FUNCTON  DESCRIPTION: 
COMMENTS: 


VRS  (11/34) 

SPEC. MAC 

Places  the  terminal  identifier  in  1st  buffer 
position  and  saves  the  next  position  as 
current  location  pointer  and  last  valid  input 
pointer 

BLOBRF 

SP.ENR 

SP.LST 

SP.SMD 

SP.WRN 


US. BEG 
US.TRM 
US. CUR 
US.IND 

SP.CLR 

Input:  RO  USB  address. 


MODULE  NAME: 


PROGRAM: 


SOURCE  FILE: 


PURPOSE: 


CALLING  ROUTINES: 


CALLING  SEQUENCE: 


COMMON: 


SUBROUTINES  CALLED: 


SP.CLR 


VRS  (11/34) 


SPEC. MAC 


Clear  the  buffer  positions  not  used,  that  is, 
those  following  the  current  buffer  position  as 
defined  by  US. COR. 


.LVBUF 
US. CUR 
US . BEG 

None 


FUNCTION  DESCRIPTION:  Input:  RO  -  USB  address, 
COMMENTS: 
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jmnt  -nrr.^r  ‘ 


MOCULE  NAME: 


SP.CSV 


PROGRAM; 

SOURCE  PILE: 

PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 
COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 


VRS  (11/34) 

SPEC. MAC 

To  call  SP.CAR  for  preparation  to  send  message 
DAP 


SP.CAR 

INPUT:  user  status  block  address. 


COMMENTS: 


MODULE  NAME 


SP.DIS 


PROGRAM: 

SOURCE  FILE: 

PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 
COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 

COMMENTS: 


11/34  VRS 
SPEC. MAC 

Initialize  USB,  reset  Touch  Tone®  line,  and 
disconnect  line 

TOGO 


US . PER 
US.CHN 
FL. DID 
US . PLG 

COMMON,  TRESET,  SIGNAL,  BACKGR 

1.  Input:  RO  -  USB  address* 

2.  Output:  Rl  -  channel  number. 

SP.DDO  is  same  as  SP.DIS  except  for  'excessive 
time'  terminator  signal  is  first  set. 
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MOPfJLB  NAME: 
PROGRAM; 

SOURCE  PILE; 

PURPOSE: 

CALLING  ROOTINES: 
CALLING  SEQfJENCE: 
COMMON; 

SOBROOTINES  CALLED: 
FACTION  DESCRIPTION 
COMMENTS: 


-3 


SP.ENR 
VRS  11/34 
SPEC. MAC 

C,l*ac  °u*  JnPut  buffer,  insert  *SOO'  for  a 
'scan  data'  request 

OAP 


PL. YER 
OS. PER 
SP.CLA 

SP.CLA 


:  Input:  RO  -  fJSB  address. 


* 


i 


r 


» 
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MODULE  NAME 


SP.ETA 


PROGRAM: 

SOURCE  PILE: 

PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 
COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 
COMMENTS: 


11/34  VRS 
SPEC. MAC 

Clears  6  characters  in  input  bu£fer  and  update 
USB  input  buffer  pointer,  US. CUR. 

DAP 

US. CUR 
SP .CAR 

Input:  R  -  USB  address- 
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SP.FCT 


MODULE  NAME: 
PROGRAM: 

SOURCE  PILE: 
PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE : 
COMMON: 


VRS  (11/34) 
SPEC. MAC 


For  En  route. mode, 
into  input  buffer 


enters  FT ' s  and  synopsis 


DAP 


SUBROUTINES  CALLED:  ASKYNO,  RPTYP 

function  DESCRIPTION:  input:  R3  input  buffer  pointer* 
COMMENTS: 
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MODULE  NAME 


SP. FDR 


PROGRAM: 

SOURCE  FILE: 

PURPOSE: 

CALLING  ROUTT WES: 
CALLING  SEQUENCE: 
COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 

COMMENTS: 


VRS  (11/34) 

SPEC. MAC 

To  determine  if  PD's  requested,  clears  C-bit 
if  yes  sets  C-bit  and  sends  data  if  not. 

DAP 


FL.PHE 

US.FLG 

SP.CAR 

1.  Input:  RO  -  US8  address- 

2.  Output:  C-bit  set  if  FD's  not  requested 
cleared  otherwise. 
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MODULE  HAMS; 

PROGRAM; 

SOURCE  PTT.g. 

PURPOSE: 

CALLING  ROUTINES; 
CALLING  SEQUENCE. 
COMMON; 

subroutines  CAr.r.gn. 

FUNCTION  DESCRIPTTnM. 


SP.  PER 
VRS  (11/34) 

SPEC. MAC 

To  add  PD- request  to  output  buffer 

DAP 

US. CUR 
as. IMP 

ASRTYNO 

Input:  ro  -  USB  address. 

R3  -  output  buffer  pointer- 


COMMENTS: 


MODULE  MAMS: 

PROGRAM: 

SOURCE  PILE:- 
PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 
COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 

COMMENTS: 


SP.PTB 
11/34  VRS 
SPEC. MAC 

Sets  report  value  to  FT#  then  calls  Check  B  to 
check  for  reports  available,  none  available 
species  none  in  effect  message 

DAP 


CHECK B  (in  SP.SAB) 

1.  Input:  R2-  FT  value* 

2.  Output:  R3  -  pointer  to  none  in  effect 
message  • 
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MODrJLE  NAME: 
PROGRAM: 

SQfJRCE  PILE; 
PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 


SP.HYP 
VRS  (11/34) 

SPEC. MAC 

Insert  a  hyphen  into  input  data 
DAP 


COMMON: 

SUBROUTINES  CAr.f.Rn. 


US.CUR 

None 


g^-TTQ«  PSSCRT PTION :  l.  mput:  RO  -  USB  address, 

2.  Output:  R3  -  points  to  current  location 
pointer  (before  hyphen).  -Location 

COMMENTS: 
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MODULE  NAME 


SP.LOB 


PROGRAM: 

SOURCE  PILE: 
PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 
COMMON: 


VRS  (11/34) 

SPEC. MAC 

Por  Bn  route  mode;  enters  SA's,  UA’s,  NO's 
into  output  -buffer 

DAP 


SUBROUTINES  CALLED:  ASKYNO,  RPTYP 

function  DESCRIPTION:  1.  Input:  R3  -  output  buffer  pointer. 

2.  Output:  R3  -  output  buffer  pointer- 


COMMENTS: 
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MODULE  NAME: 

PROGRAM; 

SOURCE  PILE; 

PURPOSE: 

CALLING  ROUTINES; 
CALLING  SEQUENCE; 
COMMON; 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION; 


SP.LOC 
VRS  -  11/34 
SPEC . MAC 

To  check  if  loc  entered  is  valid  format  and  if 
10  Iocs  entered. 

DAP 


US.INP  PL.LST 

US. CUR  PL. LOC 

US.RCV 
US . PER 

INVALK 


1.  Input:  R0  -  USB  address- 

2.  Output:  US. PER  -  last  loc  flag  set  on  10th 

loc 

-  loc  entered  flag  set  if 
format  valid 

US.RCV+2  *  increment  total  of  Iocs 
entered 

C-bit  -  set  for  abnormal  exit  - 
invalid  loc  or  10th  loc. 


COMMENTS 


MODULE  NAME 


SP.LST 


PROGRAM: 

SOURCE  FILE: 
PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 
COMMON: 


SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 

COMMENTS: 


VRS  (11/34) 

SPEC. MAC 

Checks  if  loc  entered  was  last  loc  and/or 
correction  mode  if  not:  normal  return  to  DAP, 
if  yes,  the  data  are  sent.  If  select  mode,  the 
report  types  are  also  sent' 

DAP 


FL.LST 

RDQUE 

US . PER 

TR.QUE  -  QUEUE  trap  address 

FL.COR 

US . DAP 

FL.YER 

US . BRF 

US.RCV 

US. CUR 

US . BEG 

DISPL2,  SP. 

BBL.  SP.CAR,  SP.CLA 

1.  Input  - 

RO  -  USB  address. 

2.  Output  -  C-bit  set  if  not  local  mode 
briefing  when  iast  location  processed* 
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MODULE  NAME 


SP. MOD 


PROGRAM: 

SOURCE  FILE: 

PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 
COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 

COMMENTS: 


VRS  -  11/34 
SPEC. MAC 

Checks  if  last  response  a  159  -  if  yes 
sets  up  for  briefing  mode  query 

DAP 


US. CUR 
US. DAP 

None 

1.  Input:  RO  USB  address. 

2.  Output:  #2  in  dialogue  protocol  US. DAP- 

This  is  not  used  (commented  out)  while  in 
prompt  mode  only. 


MODULE  NAME 


SP.5AB 


PROGRAM: 

SOURCE  FL5: 
PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 
COMMON: 


SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 


11/34  VRS 
SPEC. MAC 

Check  foe  SA's  available,  if  not,  speak  'none 
in  effect'  message 

DAP 


US.RPT 
NONEFF 
DP. ABN 
NS . DAP 
FL.DIS 
US . FLG 

SPEAR 

1.  Input:  RO  -  USB  address. 

2.  Output:  R3  -  pointer  to  message  to  be 
spoken. 


COMMENTS 


MOQfJLS  MAME: 

PROGRAM: 

SOCJBCE  PItiB: 

P0RP03E: 

CALLING  ROOTINBS: 
CALLING  SSQrjBNCB: 
COMMOM: 

StJBRQfJTINBS  CALLED: 
PTJMCTIOM  DESCRIPTTflM 


SP.SMD 
VRS  (11/34) 
SPEC. MAC 


o  determine  if  briefing  mode  is  'Bn  route 
Prompt*  and  points  to  proper  dialogue. 

DAP 


as . BRP 
as . DAP 

SP.CLA 

:  Input:  rO  -  aSB  address - 


COMMENTS 


MODULE  NAME 


PROGRAM; 
SOURCE  FILE; 
PURPOSE; 


CALLING  ROUTINES; 
CALLING  SEQUENCE; 
COMMON; 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION; 


1.  SP. SYR 

2.  SP. NOT 

3.  SP.FTR 

4.  SP.PRP 

5.  SP.SAS 

11/34  VRS 
SPEC. MAC 

To  put  request  in  output  buffer  for: 

1.  Synopsis 

2.  NOT AMS 

3.  Terminal  Forecasts  (FT) 

4.  Pilot  REports  (UA) 

5.  Surface  observations  (SA's) 

DAP 


ASRYNO,  RPTUP 

1.  Input:  R3  -  output  buffer  pointer. 

2.  Output:  r3  -  updated  output  buffer  pointer 
past  inserted  request- 


COMMENTS 


MODULE  NAME: 

PROGRAM: 

SOURCE  PILE: 

PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 
COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 
COMMENTS: 


SP.TIM 

VRS  (11/34)  « 

SPEC. MAC  f 

Gets  present  time,  disables  Touch-Tone®  input,  '• 

speaks  time,' and  initializes  users  buffer. 


US.SAl  FL.DIS 

US.FLG 

US. CUR 

ECHO,  COMMON,  GETTIM 
Input:  RO  -  USB  address. 
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HOPPLE  NAME: 

PROGRAM: 

SOPRCE  PILE: 

PORPOSE: 

CALLING  ROPTINES: 
CALLING  SEQPENCE: 

COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 

COMMENTS: 


SP.WMD 
VRS  (11/34) 

SPEC. MAC 

Checks  if  briefing  mode  local  if  not, 
returns.  If  yes,  pops  return  address  of 
stack,  sets  dialogue  protocol  for  local  and 
jumps  to  DAP, 

DAP 


OS. DAP 
OS . 8RP 

None 

1.  Input:  RO  -  OSB  address. 

2.  Output:  OS. DAP  set  to  6  if  briefing  mode 
local. 
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MODULE  NAME 


SP.WRN 


PROGRAM: 

SOURCE  PILE: 

PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 
COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 
COMMENTS: 


VRS  (11/34) 

SPEC. MAC 

Puts  briefing  mode  (En  route.  Select,  or 
Prompt:  into. output  buffer 

DAP 

US. CUR 
US. DAP 
US.BRF 

SP.CLA,  SP.CAR 

Input:  RO  -  USB  address. 
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MODULE  NAME 


SYNALT 


PROGRAM: 

SOURCE  PILE: 

PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 
COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 

COMMENTS: 


(11/34}  VRS 
SPEC. MAC 

Check  altitude  input  for  proper  format  and 
value  alt  -  either  greater  than  1000  ft  or 
less  than  45999  with  either  two  digit  or 
4  digit  input 

SYNTAX  (SPEC. MAC) 


NUMIN,  NINVAL,  OKVAL 

1.  input:  R3  -  input  buffer  pointer 

R4  -  No.  of  characters 

2.  Output:  Either  clear  or  set  C-bit  for 
valid  or  invalid  syntax* 
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MODULE  NAME 


SYNBTA 


PROGRAM: 

SOURCE  FILE: 

PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 
COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 


<11/34 )  VRS 
SPEC. MAC 

Check  syntax  of  ETA  (winds)  time  characters  in 
input  buffer. and  adds  'z*  for  zulu  time 

SYNTAX  (SPEC. MAC) 


US .CUR  -  current  input  pointer 
NUMIMP,  NINVAL,  ORVAL 

1.  Input:  R4  -  No.  of  characters. 

R3  -  pointer  to  input  array. 

2.  Output:  US. CUR  is  updated* 


COMMENTS 


MODULE  NAME: 


SYNHR 


PROGRAM: 

SOURCE  PILE: 

PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 
COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 

COMMENTS: 


(11/34)  VRS 
SPEC. MAC 

Check  hour  value  input  foe  winds  report  must 
be  numeric  and  less  than  or  equal  to  30  hours 

SYNTAX 


NINVAL,  OKVAL,  NUMIMP 

1.  Input:  R3  -  input  buffer  pointer 

R4  -  No.  of  characters. 

2.  Output:  C-bit:  Cleared  for  valid  format 
or  value  set  for  invalid* 
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MODULE  nmE: 


SYNTAX 


PROGRAM; 

SOURCE  PILE: 

PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 

COMMON: 

SUBROUTINES  CALLED: 

FUNCTION  DESCRIPTION: 

COMMENTS: 


(11/34)  VRS 
SPEC. MAC 

Check  input  buffer  characters  for  appropriate 
subroutine  to  call  to  check  format 

ALPHA  DAPCOM  YESCK 

INVALN  -  called  by  NUMBER  (SPEC. MAC) 

VALID,  INVALY  -  call  by  YESCK  (SPEC. MAC) 

INVALT  -  call  by  WETPCK 

SYNFLG  -  first  pass  flag 
NUMFLG  -  numeric  flag 
rJSINP 

ALPHA,  SYNHR,  SYNALT,  SYNETA,  WETPCK,  YESCK, 
VALID 

1.  Input:  R2  -  buffer  pointer. 

2.  Output:  C-bit  set  for  invalid  format. 

Following  are  ’mini’  -  routines  contained  in 
Syntax 

INVALA  sets  invalid  alpha  flag  in  3T.3NV  - 
into  R3 

INVALN  sets  invalid  number  flag  in  ST.SNV  - 
into  R3 

INVALT  sets  invalid  type  flag  in  ST.SNV  - 
into  R3 

INVALY  sets  invalid  Y/N  flag  in  ST.Sny  - 
into  R3 

INVALU  -  modifies  the  line  status  flag 
according  to  the  above  flags  that  had  been 
set. 


MODULE  NAME 


WETPCR 


PROGRAM: 

SOURCE  PILE: 

PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 
COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 

COMMENTS: 


(11/34)  VRS 
SPEC. MAC 

Check  input  buffer  for  valid  weather  type 
SYNTAX  (SPEC.  MAC) 


PL.DHB 

US.FLG 

SYNFLAG  -  hold  weather  type  characters 
VALID,  INVALT 

Input:  R3  -  input  buffer  pointer- 

Output:  If  winds  report,  'ED';  sets  PD  flag 

in  US.FLG* 
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MODULE  NAME: 


PROGRAM: 


SOURCE  PILE: 


YESCK 

(11/34)  VRS 
SPEC. MAC 


1 


PURPOSE: 


Check  input  buffet  for  valid  yes  or  no 
response.  Prompt  must  call  for  4/n  and  4/N 
must  be  in  right  format. 


CALLING  ROUTINES: 


SYNTAX  (SPEC. MAC) 


CALLING  SEQUENCE: 
COMMON: 


USB  parameters: 

PL. YES 

US . PLG 

PL. YER 

US . PER 

PL.  NO 


SUBROUTINES  CALLED:  VALID,  INVALY  (SYNTAX) 


PUNCTION  DESCRIPTION:  1.  Input: 


2.  Output: 


RO 

R3 

R1 

R2 

R2 


USB  address 
input  buffer  pointer 
protocol  mask  pointer, 
50  for  no  response 
47  for  a  yes  response. 


COMMENTS: 
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MODULE  NAME: 

PROGRAM? 

SOURCE  PILE: 

PURPOSE; 

CALLING  ROUTT WES: 
CALLING  SEQUENCE; 
COMMON: 

SUBROUTINES  CALLED; 
FUNCTION  DESCRIPTION; 

COMMENTS: 


MAP 

(11/34)  VRS 
SPEAK. MAC 

Maps  4K  memory  segments 
REAX 


HALT 

1.  Saves  RO  on  the  stack- 

2.  Sets  up  window  offsets  and  maps  the  region. 

3.  If  error,  calls  HALT  routine  which  bolts 
the  processor. 

4.  Restores  RO  and  exits. 
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MODULE  NAME 


READ 


PROGRAM: 

SOURCE  PILE: 

PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 
COMMON: 

SUBROUTINES  CALLED: 

FUNCTION  DESCRIPTION: 

COMMENTS: 


11/34  VRS 
SPEAK. MAC 

Reads  data  from  vocabulary  disk 
SPEAK R 

JSR  PC,  READ 

All  TR. ***  as  defined  in  PREFIX. MAC 

US.*** 

PL.*** 

BQ. *** 

TRAP  TR.DQE  HALT 

TRAP  TR.QUE  MAP 

1.  Gets  a  queue  element  from  fill  pool  and 
puts  it  on  read  list  head. 

2.  Performs  mapping  if  necessary, 

3.  Issues  a  . READC  request  to  disk- 


MODULE  NAME; 


REA  DC 


PROGRAM: 

SOURCE  PILE: 

PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 
COMMON: 

SUBROUTINES  CALLED: 

FUNCTION  DESCRIPTION: 


COMMENTS: 


(11/34)  VRS 
SPEAK. MAC 

Read  completion  routine  foe  disk  (reading 
speech  file) 

READ 

Called  at  completion  of  a  . READC  request 


All  TR.***  as  defined  in  PREFIX. MAC 

US .  *  *  * 

FL .  *  *  * 

MAP 

HALT 

1.  If  error  on  previous  read,  prints  error 
message  - 

2.  Calculates  USB  address 

3.  Saves  r2,  R3 ,  R4 ,  r5  on  the  stack. 

4.  Moves  Queue  element  from  read  queue  to  talk 
list  head, 

5.  Maps  user  into  extended  memory  buffer. 

6.  issues  a  .WRITE  request  to  ADPCM  output 
device. 

7.  Restores  USB  address  and  saved  registers, 
enables  Touch-Tone®  and  exits/ 


-93 


MODULE  NAME 


SPEAK R 


PROGRAM: 

SOURCE  FILE: 

PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 
COMMON: 

SUBROUTINES  CALLED: 

FUNCTION  DESCRIPTION: 

COMMENTS: 


(11/34)  VRS 
SPEAK. MAC 

Queue  speak  buffer  and  issue  reads  to  disk  for 
speech  data 

SPEAKST 

JSP  PC,  SPEAKR 


All  ST.***  as  defined  in  PREFIX. MAC 

FL.*** 

US. *** 

READ 

TYRANT 

1.  Records  speak  indication  in  USB. 

2.  Queues  element  onto  speak  queue- 

3.  Extracts  message  fields 

4.  Initiates  double-buffered  disk  reads* 

5.  Exits, 
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MODULE  NAME 


SPKST 


PROGRAM: 

SOURCE  FILE: 

PURPOSE: 

CALLING  ROUTINES: 

CALLING  SEQUENCE: 
COMMON: 

SUBROUTINES  CALLED: 

FUNCTION  DESCRIPTION: 


11/34  VRS 
SPEAR. MAC 

Sets  up  speech  buffers 

Completion  routine  from  MARKTIME  issued  in 
speak  module 


All  TR.***  as  defined  in  PREFIX. MAC 

US. *** 

PL.*** 


TRAP  TR. USB 
SPEARR 

1.  saves  R2,  R3,  R4 ,  RS  on  the  stack. 

2.  Gets  USB  address. 

3.  Sets  speak  indicator  in  USB  and  executes 
speak  routine- 

4.  Clears  speak  indicator* 

5.  Restores  saved  registers  and  returns. 


COMMENTS 


MODULE  NAME: 


TYRANT 


PROGRAM: 
SOURCE  FILE: 
PURPOSE: 


CALLING  ROUTINES: 
CALLING  SEQUENCE: 
COMMON: 


SUBROUTINES  CALLED: 

FUNCTION  DESCRIPTION: 


COMMENTS: 


(11/34)  VRS 
SPEAK . MAC 

Controls  speaking  process.  Sets  1st  block 
address,  number  of  blocks  and  last  words. 
Returns  if  end  of  message  and  not  hanging  up. 
Dequeues  element  from  message  queue,  queues 
the  last  message  buffer  to  free  pool  queue  and 
requests  next  message  if  end  of  briefing  or 
hang  up,  indicates  end  of  briefing  and  enables 
Touch  Tone®  Input. 

MORSPK  WRITC  SPEAKR 


US. 1st  FL.INT  TR.DQE 

US.FLG 

US.NUM 

US.BLK 

US. MSG 

US.  PER 

US.DMB 

INCREQ 

BLDBRF 

SENDRT 

1.  Input:  RO  -  USB  address. 

2.  Output:  US.NUM  (RO)  number  of  consecutive 

blocks. 

US.LST  (RO)  number  of ' words  in 
last  block- 

US.BLK  (RO)  address  of  1st  block- 
US.MJG  (RO)  updated  pointer  for 
next  speak  .pass. 

US.FLG  (RO)  end  of  talk  mode  flag 
set  if  end. 
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MODULE  NAME: 


WRITC 


PROGRAM: 

SOURCE  RILE: 

PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 

COMMON; 

SUBROUTINES  CALLED: 

FUNCTION  DESCRIPTION: 


(11/34)  VRS 
SPEAR . MAC 

Write  completion  routine  for  ADPCM  output 
READC 

This  is  completion  routine  for  .WRITC. in  READC 
module* 


All  TR. ***  as  defined  in  PREFIX. MAC 

US. *** 

PL.*** 

ST.*** 


TRAP  TR.QUE 
TRAP  TR.DQE 
TYRANT 
READ 
SIGNAL 

1.  If  error  on  write,  prints  error  message. 

2.  Saves  R2,  R3 ,  R4,  R5  on  the  stack- 

3.  Calculates  USB  address  if  illegal  USB 
address,  prints  a  message* 

4.  Returns  speech  element  to  free  pool- 

5.  Gets  next  message  field  and  reads  from  disk. 

6.  Restores  saved  registers  and  exits. 


COMMENTS 


MODULE  NAME: 

PROGRAM: 

SOURCE  PILE: 

PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 

COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 

COMMENTS: 


f 

* 


1 

i 
1 

ALARM/ALARMP 

11/34  i 

SENO.MAC  *' 

Alerts  the  operator  if  task  RETREV  or  VREXEC  * 

is  not  running  *# 

RCVER,  CLKRPT  , 

If  a  processor  (VREXEC)  alarm,  jump  to  ALARMP. 

I _  a  RETREV  alarm,  jump  to  ALARM. 


None 

Rings  the  terminal  bell  10  times  and  types  one 
of  the  following  messages: 

1.  RETREV  NOT  RUNNING.  VRS  ABORTING. 

2.  PROCESSORS  NOT  RUNNING. 

The  system  exits  if  message  #1  was  typed. 


* 
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MO DOLE  NAME: 


BLDBRF 


PROGRAM:  11/34  VRS 

SOPRCE  PILE:  SEND. MAC 

PURPOSE:  Composes  a  demand  request 

CALL I MG  ROUTINES:  SPEAK,  DXSCON,  DISPLA,  RPTSKP 

CALLING  SEQUENCE:  RO  -  User  Status  Block  pointer 

R2  «  Demand  request  type 

COMMON: 

SOBROOTINES  CALLED:  SP.CLA 

function  DESCRIPTION:  Composes  a  demand  request,  storing  it  in  the 

"current  input  location"  pointed  to  by  word  2 
of  the  USB,  and  getting  the  channel  and  demand 
request  number  from  the  USB. 


COMMENTS: 


MODULE  NAME 


CHKREQ 


PROGRAM: 

SOURCE  PILE: 

PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 
COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 

COMMENTS: 


(11/34)  VRS 
SEND. MAC 

Check  ASCII  Channel  Number. 

DISCON,  RPTSKP 
RO  »  points  to  USB. 

TRAP  TR.DQE 

Compares  the  ASCII  channel,  number  in  the  USB 
with  the  one  in  an  11/70  receive  QUEUE  element. 


MODULE  NAME: 


OISPLA 


PROGRAM: 

SOURCE  RILE: 

PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 
COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 


(11/34)  VRS 
SEND. MAC 

Initiates  sends  to  the  11/70  and  fields  the 
responses 

SPEC 


SPEAK,  SEND,  BLDRF,  COMMON 

Briefing  requests  are  sent  and  the  address  of 
the  start  of  the  coding  which  fields  the 
responses  is  stored  in  u.S.  RTN  (by  SEND)  for 
the  channel.  This  address  is  returned  to  from 
BACKGR  when  a  read  completes  later  on.  When 
that  happens,  the  various  response  formats  are 
checked  for:  the  message  acceptable  response, 
the  diagnostic  responses,  and  the  type  2 
message  unit  responses. 


COMMENTS 


MODULE  NAME: 

PROGRAM: 

SOURCE  FILE: 

PURPOSE: 

CALLING  ROUTINES: 

CALLING  SEQUENCE: 
COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 


COMMENTS: 


RCVC 

(11/34)  VRS 
SEND. MAC 

Fields  data  sent  from  11/70 

Completion  routine  for  the  .READC  issued  in 
module  RCVEX 

R4  points  to  FWA  of  data  buffer 


SIGNAL ,  ALARM,  DEFUSB ,  TR.DQE,  TR.QUE 

Randles  the  two  types  of  11/70  messages 
queueing  them  for  the  appropriate  processing. 

A  validity  check  is  performed  and  if  the 
message  is  not  a  valid  briefing  request 
acknowledgment  not  a  briefing  message  unit, 
the  error  path  checks  for  RETREV  log-on 
echoes,  which  are  sent  to  the  terminal,  or  for 
*1,  indicating  a  response  by  RETREV  to  a  poll 
message  sent  by  the  11/34  every  7  seconds,  or 
for  *2,  sent  by  RETREV  if  the  weather 
processors  do  not  wake  up  every  15  minutes.  A 
branch  is  made  to  ALARM  when  *2  is  received. 
When  *1  is  received  a  new  20-second  MKTM 
issued  (after  cancelling  the  one  in  effect) . 


f 
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MODULE  NAME 


RCVEX 


PROGRAM: 

SOURCE  FILE: 

PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 
COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 

COMMENTS: 


(11/34)  VRS 
SEND . MAC 

Receive  protocol  for  11/70  to  11/34 
communication 

RCVC 


RCVC  completion  routine,  TR.DQE,  TR^QUE 

Fetches  an  available  QUEUE  address  and  issues 
a  read  with  completion  on  Channel  3. 
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MODULE  NAME: 


SEND  -  SENDRT 


PROGRAM: 

SOURCE  FILE: 

PURPOSE: 

CALLING  ROUTINES: 

CALLING  SEQUENCE: 

COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 


(11/34)  VRS 
SEND. MAC 

Sends  a  byte  string  to  the  11/70 

DISPLA  RPTSKP 

DISCON  TSTRCV 

R3  ■  Data  buffer  start  address 
R4  ■  Data  buffer  length 

SENDC,  the  completion  routine. 

None 

Writes  a  string  of  bytes  to  the  11/70  on 
channel  4.  A  checksum  is  computed  and 
appended  to  the  data. 


COMMENTS: 


MODULE  NAME; 

PROGRAM: 

SOURCE  PILE: 

PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 

COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 

COMMENTS: 


INCREQ 
(11/34)  VRS 
SEND. MAC 

Increment  the  ASCII  message  unit  number  by  one. 
RPTSKP,  SPEAK 

RO  *  user  status  block  pointer 
R5  *  Message  unit  number  USB  offset 


Increments  the  4-character  ASCII  message  unit 
number  by  one. 
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MODULE  NAME: 

PROGRAM; 

SOURCE  PILE: 

PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 
COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 

COMMENTS: 


TSTRCV 
(11/34)  VRS 
SEND. MAC 

Validity  check  on  message  unit  data 
DAP 

R4  points  to  start  of  input  buffer. 


BLDBRF,  SEND  (SENDRT) 

Checks  message  unit  pairs  for  validity.  If 
the  block  number  of  a  pair  is  invalid,  the 
briefing  request  is  rebuilt  and  sent  to  the 
11/70  again. 


* 
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MODULE  NAME: 


EXIT 


PROGRAM: 

SOURCE  PILE: 

PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 

COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 


(11/34)  VRS 
PURGE. MAC 

Exit  routine  for  11/34  VRS 
BACKGR 

NXTEXT  sets  EXITFL  signal  for  BACKGR  when  a 
Terminal  input  of  'EXIT'  received 


TRESET,  MRKTTM,  DISABLE,  STRT 

1.  Closes  o  each  line  channel  to  ADPCM 

hardware  and  disable  each  Touch 
Tone®  line 
o  Dictionary  file. 

2.  Sends  exit  message  to  11/70  program  RETREV 

o  closes  input  channel  to  11/70 
o  closes  output  channel  to  11/70 
o  closes  Touch-Tone  (MCX)  channel 
o  closes  ADPCM  channels. 


COMMENTS 


MODULE  MAMEs 


CLKRPT 


PROGRAM: 

SOURCE  PILE: 

PURPOSE: 

CALLING  ROUTINES: 

CALLING  SEQUENCE: 
COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 

COMMENTS: 


(11/34)  VRS 
CLOCK. MAC 

Tics  the  VRS  clock  and  attends  to  certain 
real-time  scheduled  functions 

Completion  routine  to  a  1-sec  MRKT,  issued  by 
STRTTM  and  issued  each  time  thereafter  by 
itself 


SNDPOI 

ALARM 

When  a  1-sec  MRKT  expires,  a  second  is  added 
to  the  seconds-past-midnight  counter.  Every  7 
seconds,  a  poll  message  (ESC  NULL)  is  sent  to 
RETREV.  Also,  a  check  is  made  for  delays  in 
11/70  responses  (in  SNDPOI). 


MODULE  NAME 


GETTIM 


PROGRAM: 

SOURCE  PILE: 

PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 
COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 

COMMENTS: 


(11/34)  VRS 
CLOCK. MAC 

Put  current  time  of  day  into  LVM50  Touch-Tone® 
input  buffer. 

SP.TIM 

$MLT ,  SDVI,  SICO 

Converts  time  to  ASCII  (hhmm)  and  stores  in 
Touch-Tone  input  buffer* 


i 


1 


MODULE  NAME 


*DVT 


PROGRAM: 

SOURCE  PILE: 
PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 


COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 

COMMENTS: 


i 


y 

* 

f 


(11/34)  VRS 
CLOCK. MAC 

Integer  divide  routine 
GETTIM 

R4  *  HI  order  dividend 
R3  *  LO  order  dividend 
Rl  ■  divisor 

RETURNS:  R4  »  HI  order  quotient 
'  R3  *  LO  order  quotient 


None 

Divides  a  32-bit  dividend  by  a  16-bit  divisor 
for  a  32-bit  quotient. 
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MODULE  NAME: 
PROGRAM: 

SOURCE  FILS: 
PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 


SMLI 

11/ 3 4  VRS 
CLOCK. MAC 

Integer  multiply  routine 
GETTIM 

R4  *  HI  order  multiplicand 
R3  *  LO  order  multiplicand 
Rl  «  multiplier 

RETURNS:  R4  »  HI  order  product 
R3  »  LO  order  product 


COMMON: 

SUBROUTINES  CALLED: 

FUNCTION  DESCRIPTION:  Multiplies  a  32-bit  multiplicand  by  a  16-bit 

multiplier  for  32-bit  product- 


COMMENTS: 


t 


'i 

I 


t 

j 
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MODULE  NAME 


TR.HAN 


PROGRAM: 

SOURCE  FILS: 

PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 
COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 


11/34  VRS 
TRAP. MAC 

Handles  entry  to  all  TRAP  routines 
BACRGR  DAP  SPEC 
TRAP  TR.*** 

TR.LST 

All  TRAP  routines  (TRAP. TR. ***) 

1.  Gets  TRAP  code  from  stack. 

2.  Checks  for  legal  TRAP  code' 

3.  Resolves  address  of  desired  TRAP  routine. 

4.  Enters  routine  via  JSR. 

5.  On  return  from  routine  does  error  checking. 

6.  Returns  via  RTI. 


COMMENTS 


MODULE  NAME: 

PROGRAMS 
SOURCE  PILE: 

PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 
COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 

COMMENTS: 


1 


TR.MOD  (MODLSB) 

11/34  VRS 
TRAP. MAC 

Modifies  line  status  field  of  tjsb. 

RING 

TRAP  TR.MOD 

ALL  TR.***  As  defined  in  PREFIX. MAC 
US. *** 

FL. *** 

SP. *** 

DP. *** 

TRACE 

1.  Places  Rl  in  line  status  field. 

2.  If  input  received  from  11/70,  clears 
line  timeout  flag  in  clock. 

3.  Performs  a  trace. 

4.  Returns. 

This  routine  is  entered  thru  a  TRAP  vector 
in  order  to  change  processor  priority  to  7, 
thus  preventing  device  interrupts  from 
changing  vital  parameters. 
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module  name 

PROGRAM: 


SOURCE  FILE: 

PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 
COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 


TR.SIG  (SIGMAN) 

11/34  VRS 

TRAP. MAC 

Signal  flag  modification  routine 

BACKGR 

TRAP  TR.SIG 


None 


1.  Moves  BITMSK  into  R1  and  clears  BITMSK. 

2.  Moves  BITMSK+2  into  R2  and  clears 
BITMSK+2 

3.  Returns, 

This  routine  is  entered  thru  a  TRAP  vector 
in  order  to  change  processor  priority  to  7, 
thus  preventing  device  interrupts  from 
changing  vital  parameters. 


COMMENTS 


MODULE  NAME: 

TR.SPK 

PROGRAM: 

11/34  VRS 

SOURCE  PILE: 

TRAP. MAC 

PURPOSE: 

Executives  SPEAK  routine 

CALLING  ROUTINES: 

SPEAKR 

CALLING  SEQUENCE: 

TRAP  TR.SPK 

COMMON: 

ALL  TR. ***  as  defined  in  PREFIX. MAC 

US.*** 

FL.*** 

SP.*** 

DP.*** 

SUBROUTINES  CALLED: 

TRAP  TR.QUE 

FUNCTION  DESCRIPTION: 

1.  QUEUES  message  pointer  into  SPEAK  QUEUE 

2.  Checks  to  see  if  done  talking.  If  so, 
returns  with  carry  bit  clear.  If 
still  talking,  returns  with  carry  bit 
set. 

COMMENTS: 

This  routine  is  entered  thru  a  TRAP  vector 
in  order  to  change  processor  priority  to  7, 
thus  preventing  device  interrupts  from 
changing  vital  parameters. 
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MODULE  NAME: 

PROGRAM? 

SOURCE  PILE: 

PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 
COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 

COMMENTS: 


TR.USB  (DEFUSE) 

11/34  VRS 
TRAP. MAC 

Calculates  USB  address  from  channel  #  in  RO  * 

MCX . SYS  r 

TRAP  TR.USB  - 

All  TR.***  as  defined  in  PREFIX. MAC  1 

US.***  • 

PL.*** 

SP.*** 

DP.*** 


None 

1.  Checks  for  legal  channel  ♦. re turns 
with  C-bit  se*  if  error. 

2.  Multiples  channel  I  by  64  and  adds 
base  address  of  USB. 

3.  Returns. 


« 
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MODULE  NAME: 

PROGRAM: 

SOURCE  FILE: 

PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 

COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 


COMMENTS: 


t 

S 


TR.DQE  (DQUEUE) 

11/34  VRS 
QUEUE. MAC 

Removes  one  element  from  AQUEUE  list 

BACKGR, DAP, SPEC 

MOV  IQLIST,  R3 
TRAP  TR.DQE 


None 

1.  Address  of  a  queue  list  header  is 
placed  in  R3. 

2.  Routine  exits  with  carry  bit  set  if 
no  elements  in  list. 

3.  List  header  and  tail  pointer  are 
adjusted. 

4.  Routine  exits  with  R4  containing 
address  of  QUEUE  element. 

This  routine  is  entered  thru  a  TRAP  vector 
in  order  to  change  processor  priority  to  7, 
thus  preventing  device  interrupts  from 
changing  vital  parameters. 
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MODULE  NAME? 
PROGRAM; 

SOURCE  FILE: 
PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 


COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 


COMMENTS: 


TR.QUE  (EQUEUE) 

11/34  VRS 
QUEUE. MAC 

Inserts  one  element  into  QUEUE  list 

B AC KG R, DAP, SPEC 

MOV  IQLIST,  R3 
MOV  IELADDR,  R4 
TRAP  TR.QUE 


None 

1.  Address  of  QUEUE  list  reader  is  placed 
in  R3 . 

2.  Address  of  QUEUE  element  is  placed  in 
R4. 

3.  List  reader  and  tail  pointer  are 
adjusted. 

4.  Routine  exits  with  carry  bit  clear. 

This  routine  is  entered  thru  a  TRAP  vector 
in  order  to  change  processor  priority  to  7, 
thus  preventing  device  interrupts  from 
changing  vital  par amen ter s. 
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MODULE  NAME; 


TRACE 


PROGRAM: 

SOURCE  FILE: 

PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 
COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 


COMMENTS: 


11/34  VRS 


TRACE. MAC 


Creates  a  statistical  data  file  VRDATA.DAT. 


TR.MOD  (MODLSB) 


Fills  a  buffer  with  selected  data  from  the 
User  Status  Block  for  each  briefing 
performed  and  writes  it  to  a  revolving 
file,  VRDATA.DAT,  along  with  a  record 
pointer  block  in  block  0  and  data  record 
definitions  prepended  to  each  briefing's 
record.  Upon  initialization  of  VRS,  if  no 
file  exits  on  disk,  it  is  created.  If  one 
exits  but  was  not  concluded  during  a  normal 
exit,  the  file  is  scanned  and  a  record 
pointer  block  constructed. 
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MODULE  NAME: 


TABLE 


PROGRAM; 

SOURCE  FILE: 

PURPOSE; 

CALLING  ROUTINES: 
CALLING  SEQUENCE; 

COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 


COMMENTS: 


11/34  VRS 
TABLE. MAC 

Steps  each  user  channel  through  the  system 
dialogue. 

DAP 

Twice  the  value  in  US. DAP  (RO)  added  to  the 
top  address  of  TABLE  (VECTOR)  yields  the 
address  of  the  desired  table. 

The  special  function  entry  points,  SP.xxx. 

None 

For  each  step  of  the  dialogue  protocol 
there  is  a  table  of  pointers  and  flags  as 
follows: 

1.  A  word  of  flags  indicating  certain 
temporary  conditions,  and  expectations. 

2.  Address  of  any  special  function, 
necessary  before  speaking  a  prompt. 

3.  Wait  interval  before  speaking  prompt. 

4.  Wait  interval  before  speaking  echo. 

5.  Flag  if  to  repeat  same  utterance  after 
response. 

6.  Address  of  the  prompt  message  units. 

7.  Address  of  any  special  function 
necessary  to  user  syntax  analysis. 

8.  Address  of  masks  used  in  syntax 
checking. 

9.  Address  of  any  special  function 
necessary  before  speaking  an  echo. 

10.  Address  of  special  function  necessary 
before  branching  to  next  function  in 
DAP. 

11.  yes  or  normal  response  branch  vector. 

12.  No  or  abnormal  response  branch  vector. 
The  elements  of  the  tables  are 
accessed  as  follows:  A  constant  stored 
in  some  address  DP. XXX  is  added  to 
current  value  of  Rl  to  point  to  the 
right  table.  Another  DP. XXX  value  is 
added  to  point  to  the  desired  element 
of  the  table. 
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MODULE  NAME; 

PROGRAM; 

SOURCE  FILE: 

PURPOSE; 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 

COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 

COMMENTS: 


a 


DICT 
VREXEC 
VOCAB . MAC 

To  translate  ASCII  text  to  Speech  File 
Pointers 

START  (DICT. MAC)  interface  module 

FORTKV  -  ASCII  text  in  AT ADI Z 
VSNDRR  DICT 

Requires  VRSDIC  for  Global  Common 


Given  the  ASCII  weather  report  text,  a 
binary  search  is  done  on  a  list  for  each 
word  to  obtain  the  vocabulary  file  pointers 
and  record  lengths  to  be  sent  to  the  11/34 
VRS. 
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MODULE  NAME: 

PROGRAM: 

SOURCE  FILE: 

PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 

COMMON: 

SUBROUTINES  CALLED: 
FUNCTIONAL  DESCRIPTION: 


EXTHED 
VREXEC 
EXTHED. FTN 

This  subroutine  extracts  the  date/time 
group  from  a  header  report. 

VRSSA,  VRSPTR 

Call  EXTHED  (A,  ILEN) 

where:  A  -  raw  data  input  array 

ILEN  *  length  in  bytes  of  raw  data  array 


None 

To  extract  the  six-digit  header  date  and 
time  from  the  report  header  passed  to  it. 
Input: 

A  *  A  byte  array  containing  the  report 
header . 

ILEN  *  The  length,  in  bytes,  of  the 
report  header  contained  in  the  array  A. 

COMMON/ ZULU/HTIME,  IRTIM,  STIME  where 
HTIME,  IRTIM,  and  STIME  are  all 
six-byte  arrays. 

Ou  tpu  t: 

The  six-digit  header  date  and  time 
group  is  placed  into  the  six-byte 
array  HTIME  in  the  labeled  common  ZULU. 


COMMENTS 


MODULE  NAME; 
PROGRAM: 

SOURCE  FILE: 
PURPOSE : 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 


LGTNG 

VREXEC 


This  subroutine  decodes  lighting  SA  remarks. 
VRRMK 

Call  LGTNG  (WORK,  WLEN,  RMK,  RLEN,  INDX, 


IERR) 

where: 

WORK 

m 

raw  data  word 

WLEN 

* 

length  in  bytes  of  raw 
data  word 

4 

RMK 

■ 

raw  Remarks  data  array 

RLEN 

* 

length  in  bytes  of  Remarks 
raw  data  array 

INDX 

m 

current  index  position  in 
Remarks  raw  data  array 

OERR 

error  flag 

COMMON: 

SUBROUTINES  CALLED:  None 

SYSTEM  ROUTINE  REQUIRED:  INDSTR 

FUNCTION  DESCRIPTION:  To  decode  lighting  remarks  which  occur  in 

the  Remarks  portion  of  SA  reports. 

Input: 

WORD  *  A  byte  array  containing  the 
data  word  to  be  decoded. 

WLEN  *  The  length,  in  bytes,  of  the 
data  word. 

RMK  »  A  byte  array  containing  the  SA 
Remarks  data. 

RLEN  *  The  length,  in  bytes,  of  the  SA 
Remarks  data. 

INDX  *  The  current  pointer  position 
within  the  SA  Remarks  data. 

COMMON/RSTUFF/RLIST , IRNDS ,  NWX 

where  RLIST  *  A  byte  array  containing 
the  decoded  Remarks 
IRNDX  *  The  current  pointer 
position  within  the 
decoded  remoars  data. 

NWX  *  A  flag  indicating  if 
weather  data  were 
decoded  in  the 
subroutine  VISWX. 
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?!!t«dtf0ded  li9hting  phrase  is  placed 
into  the  RLIST  array  and  IRNDX  is 
appropriately  incremented. 

error  flag  which  is  set  if 
the  lighting  remark  cannot  be  decoded. 


MODULE  SAME:  PCPMOD 

PROGRAM:  VREXEC 

SOURCE  FILE: 

PURPOSE:  This  subroutine  decodes  precipitation  SA 

remarks  relating  to  hail  stone  size,  ground 
fog  depth,  snow  increasing,  and 
precipitation  in  inches. 

CALLING  ROUTINES:  VRRMK 

CALLING  SEQUENCE:  Call  PCPMOD  (WORD,  WLEN,  RMK,  RLEN,  INDX, 

IERR) 

where:  WORD  *  raw  data  word 

WLEN  »  length  in  bytes  of  raw 
data  word 

RMK  *  raw  Remarks  data  array 
RLEN  *  length  in  bytes  of  Remarks 
raw  data  array 

INDX  ■  current  index  position  in 
Remarks  raw  data  array 
IERR  *  error  flag 


COMMON: 

SUBROUTINES  CALLED:  none 

SYSTEM  ROUTINE  REQUIRED:  INDSTR,  INUM 

FUNCTION  DESCRIPTION:  To  decode  precipitation  remarks  which  occur 

™  in  the  Remarks  portion  of  SA  reports, 

input: 

WORD  »  A  byte  array  containing  the 
data  word  to  be  decoded. 

WLEN  »  The  length,  in  bytes,  of  the 
data  word. 

RMK  *  A  byte  array  containing  the  SA 
Remarks  data. 

RLEN  »  The  length,  in  bytes,  of  the  SA 
Remarks  data. 

INDX  »  The  current  pointer  position 
within  the  SA  Remarks  data. 
COMMON/RSTUFF/RLIST,  IRNDX ,  NWX 
where  RLIST  *  A  byte  array  containing 
the  decoded  Remarks. 

IRNDS  »  The  current  pointer 
position  within  the 
decoded  Remarks  data. 

NWX  ■  A  flag  indicating  if 

weather  data  were  decoded 
in  the  subroutine  VISWX. 


Output: 

IERR  *  An  error  flag  which  is  set  if 

the  precipitation  remark  cannot 
be  decoded. 

The  decoded  precipitation  phrase  is 
placed  into  the  RLIST  array  and  IRNDX 
is  appropriately  incremented. 


MODULE  NAME: 

INCREQ 

PROGRAM: 

11/34  YRS 

SOURCE  PILE: 

SEND. MAC 

PURPOSE: 

Increment  the  ASCII  message  unit  number  by 
one . 

CALLING  ROUTINES: 

RPTSKP,  SPEAK 

* 

CALLING  SEQUENCE: 

RO  ■  User  Status  Block  pointer 

RS  ■  Message  Unit  Number  USB  offset. 

• 

* 

ft 

• 

COMMON: 

4 

SUBROUTINES  CALLED: 

FUNCTION  DESCRIPTION: 

Input: 

R7  -  USB  pointer. 

Output: 

US.DMB  incremented  by  one. 


COMMENTS: 


f 
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MODULE  NAME: 


PRES 


PROGRAM:  VREXEC 

SOURCE  PILE: 

PURPOSE :  This  subroutine  decodes  SA  remarks  relating 

to  pressure. 

CALLING  ROUTINES:  VRRMK 


CALLING  SEQUENCE:  Call  PRES  (WORD,  WLEN ,  RMK ,  RLEN ,  INDX, 

IERR) 

where:  WORD  ■  raw  data  word 

WLEN  *  length  in  bytes  of  raw 
data  word 

RMK  >  raw  Remarks  data  array 
RLEN  *  length  in  bytes  of  remarks 
raw  data  array 

INDX  ■  current  index  position  in 
remarks  raw  data  array 
IERR  »  error  flag 


COMMON: 

SUBROUTINES  CALLED: 

None 

SYSTEM  ROUTINE  REQUIRED: 

INDSTR,  INUM 

FUNCTION  DESCRIPTION:  To  decode  pressure  remarks  which  occur  in 

the  Remarks  portion  of  SA  reports. 

Input: 

WORD  »  a  byte  array  containing  the 
data  word  to  be  decoded. 

WLEN  ■  The  length,  in  bytes,  of  the 
data  word. 

RMK  ■  A  byte  array  containing  the  SA 
Remarks  data. 

RLEN  ■  The  length,  in  bytes,  of  the  SA 
Remarks  data. 

INDX  »  xhe  current  pointer  position 
within  the  SA  Remarks  data. 

COMMON/ RSTUFF/RLI ST,  IRNDX,  NWX 

where  RLIST*  A  byte  array  containing 
the  decoded  Remarks 
IRNDX*  The  current  pointer 
position  within  the 
decoded  Remarks  data. 

NWX-  A  flag  indicating  if 

weather  data  were  decoded 
in  the  subroutine  VISWX. 
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1 


Ou  tpu  t: 

The  decoded  pressure  phrase  is  placed 
into  the  RLIST  array  and  IRNDX  is 
appropriately  incremented. 

IERR-  An  error  flag  which  is  set  if 
the  pressure  remark  cannot  be 
decoded . 

COMMENTS: 


» 


I 
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MODULE  NAME: 


RNWY 


PROGRAM: 

SOURCE  FILE: 
PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 


COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 


VREXEC 


RNWY.FTN 


This  subroutine  decoded  runway  visibility 
and  visual  range  SA  remarks. 

VRRMK 

Call  RNWY  ( INDX ,  WORD,  LENGTH,  ICALL,  IKEY, 
ING) 

where  INDX  *  current  position  in  raw 

data  array 

WORD  »  current  raw  data  word 
LENGTH  »  length  in  bytes  of  data 
word 

ICALL  ■  1  for  runway  visibility 

decode,  2  for  runway 
visual  range  decode 
ING  ■  error  flag 


None 

To  decode  runway  visibility  and  visual 
range  remarks  which  occur  in  the  REmarks 
portion  of  SA  reports. 

Input: 

INDX  «  The  current  pointer  position 
within  the  SA  Remarks  data. 

WORD  *  A  byte  array  containing  the 
data  word  to  be  decoded. 

LENGTH  *  The  length,  in  bytes,  of  the 
data  word. 

ICALL  ■  1  for  visibility  decode,  2  for 
visual  range  decode. 

IKEY  ■  Points  to  position  of  'W  or 

'VR'  within  the  data  work  being 
decoded . 

COMMON/RSTUFF/RLIST,  IRNDX ,  NWX 

where  RLIST  ■  A  byte  array  containing 
the  decoded  Remarks. 

IRNDX  »  The  current  pointer 
position  within  the 
decoded  Remarks  data. 

NWX  •  A  flag  indicating  if 

weather  data  were  decoded 
in  the  subroutine  VISWX. 
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Output: 

The  decoded  runway  phrase  is  placed 
into  the  RLIST  array  and  IRNDX  is 
appropriately  incremented. 

ING  ■  An  error  flag  which  is  set  if 
the  runway  remark  cannot  be 
decoded . 


COMMENTS: 


i 
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MODULE  NAME: 


RNYCND 


PROGRAM:  VREXEC 

SOURCE  FILE: 

PURPOSE:  This  subroutine  decodes  runway  condition  SA 

remarks. 

CALLING  ROUTINES:  VRRMK 

CALLING  SEQUENCE:  Call  RNYCND  (WORD,  WLEN ,  RMK ,  RLEN ,  INDX, 

IERR) 

where:  WORD  ■  raw  data  word 

WLEN  ■  length  in  bytes  of  raw 
data  word 

RMK  *  caw  remarks  data  array 
RLEN  *  length  in  bytes  of  remarks 
raw  data  array 

INDX  *  current  index  position  in 
remarks  raw  data  array 
IERR  ■  error  flag 


COMMON: 

SUBROUTINES  CALLED:  None 


SYSTEM  ROUTINES  REQUIRED: 


FUNCTION  DESCRIPTION:  To  decode  runway  condition  remarks  which 

occur  in  the  Remarks  portion  of  SA  reports. 
Input: 

WORD  *  A  byte  array  containing  the 
data  word  to  be  decoded. 

WLEN  ■  The  length,  in  bytes,  of  the 
data  word. 

RMK  *  A  byte  array  containing  the  SA 
Remarks  data. 

RLEN  *  The  length,  in  bytes,  of  the  SA 
Remarks  data. 

INDX  *  The  current  pointer  position 
within  the  SA  Remarks  data. 

COMMON/RSTUFF/RLIST,  IRNDX,  NWX 

where  RLIST  »  A  byte  array  containing 
the  decoded  Remarks. 

IRNDX  *  The  current  pointer 
position  within  the 
ddecoded  Remarks  data. 

NWX  ■  A  flag  indicating  if 
weather  data  were 
decoded  in  the 
subroutine  VISWX. 


Ou  tput: 

The  decoded  runway  condition  phrase  is 
placed  into  the  RLIST  array  and  irndx 
is  appropriately  incremented. 

IERR  »  An  error  flag  which  is  set  if 
the  runway  condition  remark 
cannot  be  decoded. 


COMMENTS: 


t 


I 
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MODULE  NAME: 


SKY 


PROGRAM: 

SOURCE  FILE: 

PURPOSE: 

CALLING  ROUTINES; 
CALLING  SEQUENCE: 

COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 


VREXEC 
SKY . FTN 

This  subroutine  extracts  and  decodes  sky 
cover  data. 

VRSSA 

Call  SKY  (A,  SKYCVR,  ISKILL) 
where  A  =*  raw  data  input  array 
SKYCVR  »  decoded  sky  cover  data 
ISKILL  »  flag  indicating  error  in  sky 
over  field. 


None 

To  extract  and  decode  sky  cover  data 

occurring  in  the  main  body  of  an  SA  report. 

Input: 

A  »  A  byte  array  containing  the  SA 
report  being  decoded. 

COMMON/ INDS/ IVSTART , IVEND , I SKSTR , I SKEND 
where  IVSTART  »  Points  to  beginning  of 
the  visibility  field 
in  the  SA  report. 

IVEND  »  Points  to  the  end  of 

the  visibility  field 
in  the  SA  report. 

ISKSTR  a  Points  to  the  begin¬ 

ning  of  the  sky  cover 
field  in  the  SA  report 
ISKEND  *  Points  to  the  end  of 

the  sky  cover  field  in 
the  SA  report. 

Ou  tput: 

SKYCVR  =  A  byte  array  containing  the 
decoded  sky  cover  data. 

IKILL  *  An  error  flag  which  is  set  if 
the  sky  cover  data  cannot  be 
decoded . 

COMMON/ERROR/IERROR  (10) 

where:  IERROR  is  an  integer  array 

pointing  to  any  errors  in  the 
SA  report. 

COMMON/ERRPTS/NDXERR ,  NDXTEX 
where:  NDXERR  »  Number  of  errors  in 
IERROR  array 

NDXTERX  »  Number  of  free  text 
i  terns 


COMMENTS: 


MODULE  NAME; 


SKYRMK 


PROGRAM:  VREXEC 

SOURCE  FILE: 

PURPOSE:  This  subroutine  decodes  SA  remarks  relating 

to  sky  cover,  compass  directions,  and 
miscellaneous  words. 

CALLING  ROUTINES:  VRRMK 

CALLING  SEQUENCE:  Call  SKYRMK  (WORD,  LENGTH,  RMK,  LNRMKS, 

INDX,  IBAD) 

where:  WORD  =  raw  data  word 

LENGTH  *  length  in  bytes  of  raw 
data  word 

RMK  *  raw  remarks  data  array 
LNRMKS  »  length  in  bytes  of  remarks 
raw  data  array 

INDX  »  current  index  position  in 
remarks  raw  data  array. 
IBAD  »  error  flag 


COMMON: 

SUBROUTINES  CALLED:  None 

SYSTEM  ROUTINE  REQUIRED:  I LET ,  INUM 

FUNCTION  DESCRIPTION:  To  decode  SA  Remarks  relating  to  sky  cover 

and  compass  directions. 


Input: 

WORK  a  a  byte  array  containing  the 
data  word  to  be  decoded. 

LENGTH  =  The  length,  in  bytes,  of  the 
data  word. 

RMK  ■  A  byte  array  containing  the  SA 
Remarks  data. 

LNRMKS  =  The  length  in  bytes,  of  the  SA 
Remarks  data. 

INDX  »  The  current  pointer  position 
within  the  SA  Remarks  data. 

COMMON/RSTUFF/RLIST,  IRNDX ,  NWX 

where:  RLIST  *  a  byte  array  containing 
the  decoded  Remarks 
IRNDX  3  The  current  pointer 
position  within  the 
decoded  Remarks  data. 

NWX  *  A  flag  indicating  if 
weather  data  were 
decoded  in  the 
subroutine  VISWX. 


Output: 

The  decoded  skycover  phrase  is  placed 
into  the  RLIST  array  and  IRNDX  is 
appropriately  incremented. 

IBAD  ■  An  error  flag  which  is  set  if 
the  sky  cover  remark  cannot  be 
decoded . 


F 


MODULE  NAME; 
PROGRAM; 

SOURCE  FILE; 
PURPOSE; 

CALLING  ROUTINES; 
CALLING  SEQUENCE; 


COMMON; 

SUBROUTINES  CALLED; 
FUNCTION  DESCRIPTION; 


START 
VREXE 
DICT. MAC 

Interface  between  the  main  dictionary 
translator,  VOCAB.MAC,  and  VRS 

VRINP 

VRINP  performs  a  SEND  with  R  (4)  set  to 
indicate  weather,  winds,  or  exit  (see  below) 


DICT 


1.  Performs  a  VRCS$  and  VSDR$  to  receive 
ana  send  data  stored  in  array  R: 

R  (4)  »  Process  identifier;  exit, 
winds,  weather. 

R  (6)  »  Returned  error  indicator. 

R  (7)  »  Returned  data  length. 

2.  Calls  DICT,  which  does  the  translating. 


COMMENTS; 


MODULE  NAME: 


SUBFLD 


PROGRAM: 

VREXEC 

SOURCE  FILE: 

SUBFLD. FTN 

PURPOSE: 

This  subroutine  extracts  the  following 
items  from  an  SA  report: 

1.  Report  location  identifier 

2.  Beginning  nd  end  points  of  sky  and 
visibility/weather  fields 

3.  Temperature,  dew  point,  wind 
direction,  and  speed. 

4.  Altimeter  Setting 

5.  Remarks  starting  point 

CALLING  ROUTINES: 

VRSSA 

CALLING  SEQUENCE: 

Call  SUBFLD  (A,  ILEN,  TEMP,  DP,  WIND,  DIR 
SQLL,  GUST,  ALTIM,  LOC,  IGNORE,  IK,  IRMK) 
where:  A  3  raw  data  input  array 

ILEN  ■  length  in  bytes  of  caw 
data  array 

TEMP  »  extracted  temperature 
DP  *  extracted  dew  point 
WIND  *  extracted  wind  velocity 
DIR  *  extracted  wind  direction 
SQLL  *  extracted  wind  squall 
velocity 

GUST  3  extracted  wind  gust 
velocity 

ALTIM  *  extracted  altimeter  setting 
LOC  *  location  identifier 
IGNORE3  flag  indicating  insuffi¬ 
cient  data  to  process 
IK  3  flag  indicating  error  in 
repor  t 

IRMK  3  start  position  of  Remarks 
in  raw  data  array 

COMMON: 

SUBROUTINES  CALLED:  None 

FUNCTIONAL  DESCRIPTION:  Besides  extracting  the  items  listed  above 

in  the  calling  sequence,  SUBFLD  also  sets 
the  following  flags  in  the  common  area  FLGS: 
COMMON/FLGS/ IWXFLG ,  IGFLG ,  IQFLG ,  ITFLG , 
IDFLG,  IWFLG,  IAFLG,  ISPFLG,  ICOFLG, 

IAMFLG,  IAEST,  IWEST,  IFRAC,  IVIS 
of  which  the  following  are  output  in  SUBFLD: 
IGFLG  3  A  flag  which  is  set  if  wind  gusts 
are  present. 

IQFLG  3  A  flag  which  is  set  if  squalls 
are  present. 

ITFLG  3  A  flag  which  is  set  if  temperature 
is  present. 
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IDFLG  ■  A  flag  which  is  set  if  dew  point 
is  present. 

IWFLG  «  A  flag  which  is  set  if  wind  speed 
is  present. 

IAFLG  «  A  flag  which  is  set  if  altimeter 
setting  is  present. 

ISPFLG  ■  A  flag  which  is  set  if  the  report 
is  a  SA  Special. 

ICOFLG  *  A  flag  which  is  set  if  the  report  1 
is  a  SA  correction.  «, 

IAMFLG  ■  A  flag  which  is  set  if  the  report 
is  a  SA  AMOS  or  ACJTOB  report. 

ZAEST  -  A  flag  which  is  set  if  the 

altimeter  setting  is  estimated. 

I WEST  *  A  flag  which  is  set  if  the  wind 
speed  is  estimated. 

IFRAC  *  A  flag  which  is  set  if  a 

fractional  visibility  is  present. 

COMMON/INDS/IVSTRT# I VEND »  ISKSTR,  ISKEND 

where  IVSTRT  ■  Points  to  beginning  of  the 

visibility  field  in  the  SA 
repor  t. 

IVEND  *  Points  to  the  end  of  the 

visibility  field  in  the  SA 
repor  t. 

ISKSTR  *  points  to  the  beginning  of 
the  sky  cover  field  in  the 
SA  report. 

ISKEND  *  points  to  the  end  of  the 
sky  cover  field  in  the  SA 
report. 

COMMENTS: 
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MODULE  NAME 


VDATE 


PROGRAM: 

SOURCE  FILE: 
PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 


COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 


> 

COMMENTS : 


VREXEC 
VDATE. FTN 

Converts  the  report  date  (day  of  month) 
into  a  four  digit  number  representing  the 
report  date  in  terms  of  year  and  day  of 
year . 

VRSOUT ,  VRERR,  VRSPURG 
Call  VDATE  (DAY,  DATE) 

where:  DAY  ■  report  day  of  the  month  date 

in  byte  format 

DATE  *  4  digit  integer  value 

representing  report  date  by 
year  and  day  of  year.  Last  3 
digits  »  day  of  year.  First 
digit  *  last  digit  of  current 
year,  i.e.  1  *  1981 


To  convert  a  given  day  of  the  month  value 
into  a  four  digit  number  representing  the 
day  of  the  year  and  year. 

Input: 

DAY  *  A  2- byte  array  containing  the 
day  of  the  month. 

Output: 


DATE  *  An  integer  variable  containing 
the  4-digit  value  representing 
the  year  and  day  of  the  year 
for  the  given  day  of  the  month. 
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VIS 


VREXEC 


This  subroutine  decodes  visibility  SA 
remarks 

VRRMK 


Call  VIS  (RMK,  WORK,  LNRMKS ,  LENGTH,  INDX, 
ING,  IAEND,  I RMK) 

where:  RMK  *  raw  Remark  data  array 

WORD  •  raw  data  word 
LNRMKS  »  length  in  bytes  of  Remarks 
raw  data  array 

LENGTH  ■  length  in  bytes  of  raw 
data  word 

INDX  -  current  index  position  in 
Remarks  raw  data  array 
ING  »  error  flag 
IAEND  *  length  in  bytes  of 

translated  SA  report 
contained  in  byte  array 
ALIST. 

I RMK  *  start  position  of  Remarks 
in  raw  SA  report. 

SUBROUTINES  CALLED:  None 

SYSTEM  ROUTINE  REQUIRED:  INUM,  I LET 

FUNCTION  DESCRIPTION:  To  decode  visibility  remarks  which  occur  in 

the  Remarks  portion  of  SA  report, 
input: 

RMK  *  A  byte  array  containing  the  SA 
Remarks  data. 

WORD  »  A  byte  array  containing  the 
data  word  to  be  decoded. 

LNRMKS  »  The  length,  in  bytes,  of  the  SA 
Remarks  data. 

LENGTH  *  The  length,  in  bytes,  of  the 
data  word 

INDX  ■  The  current  pointer  position 
within  the  SA  Remarks  data. 
IAEND*  The  length,  in  bytes,  of  the 

translated  main  body  SA  report. 
I RMK  ■  Points  to  the  beginning  of 
Remarks  in  the  SA  report. 
COMMON/ RSTUFF/RLI ST,  IRNDX,  NWX 
where:  RLIST  ■  A  byte  array 

containing  the  decoded 
Remarks. 


MODULE  NAME: 
PROGRAM: 

SOURCE  FILE: 
PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 
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COMMENTS : 


IRNDX  »  The  current  pointer 
position  within  the 
decoded  Remarks  data. 

NWX  *  A  flag  indicating  if 
weather  data  were 
decoded  in  the 
subroutine  VISWX. 

Output: 

The -decoded  visibility  phrase  is 
placed  into  the  RLIST  array  and  IRNDX 
is  appropriately  incremented.. 

ING  ■  An  error  flag  which  is  set  if 
the  visibility  remark  cannot 
be  decoded. 

COMMON/ERRPTS/NDXEER,  NDXTEX 
where:  NDXERR  ■  Number  of  errors  in 
IERROR  array 

NDXTEX  *  Number  of  free  text 
i  terns . 

COMMON/FRTEXT/ FRTEXR  (40),  FRTEXP  (40) 
where:  FRTEXR  *  An  integer  array 

which  points  to 
each  free  text  word 
in  the  decoded  SA 
report  data. 

FRTEXP  =  An  integer  array 
which  points  to 
each  free  text  word 
in  the  decoded  SA 
report  data. 
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MODULE  NAME: 


VISWX 


PROGRAM: 

SOURCE  FILE: 
PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 


COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 


VREXEC 
VISWX. FTN 

This  subroutine  extracts  and  decodes  the  SA 
visibility  and  weather  data. 

VRSSA 


Call  VISWX  (A, 
where:  A  » 

MILES  » 
WX  » 
IVKILL  - 


MILES,  WX,  IVKILL) 
raw  data  input  array 
decoded  visibility  value 
decoded  weather  data 
flag  indicating  error  in 
visibility/weather  field 


None 

To  extract  and  decode  visibility  and 
weather  data  occur ing  in  the  main  body  of 
an  SA  report. 

Input: 

A  *  A  byte  array  containing  the  SA 
report  being  decoded. 

COMMON/ I NDS/IVSTRT,  IVEND,  ISKSTR, 


where: 

* 

IVSTRT  » 

Points  to  beginning 
of  the  visibility 
field  in  the  SA 
report. 

IVEND  » 

Points  to  the  end 
of  the  visibility 
field  in  the  SA 
repor  t. 

ISKSTR  » 

Points  to  the 
beginning  of  the 
sky  cover  field  in 
the  SA  report. 

Outpu  t: 

ISKEND  - 

Points  to  the  end 
of  the  sky  cover 
field  in  the  SA 
repor  t. 

MILES 

»  Decoded 

visibility  value 

WX 

*  A  byte  array  containing  the 

decoded 

weather  data. 

IVKILL  ■  An  error  flag  which  is  set  if 
the  visibility/weather  data 
field  cannot  be  decoded. 


COMMON/FLGS/IWXFLG,  IGFLG ,  IQFLG, 

ITFLG t  IDFLG,  IWFLG,  IAFLG ,  ISPFLG, 
ICOFLG,  IAMFLG,  IAEST,  IWEST,  IFRAC , 

IVIS . of  which  the  following  ate 

output  in  VISWX: 

IWXFLG  *  A  flag  which  is  set  if 

weather  data  were  decoded. 
IVIS  »  Points  to  visibility  mileage 
position. 

COMMON/ERROR/IERROR  (10) 

where:  I ERROR  is  an  integer  array 

pointing  to  any  errors  in  the 
SA  report. 

COMMON/ERRPTS/NDXERR,  NDXTEX 

where:  NDXERR  *  Number  of  errors  in 

IERROR  array. 

NDXTEX  *  Number  of  free  test 
i  terns . 


MODULE  NAME; 


VRRMK 


PROGRAM; 
SOURCE  FILE: 
PURPOSE: 


CALLING  ROUTINES; 
CALLING  SEQUENCE; 


COMMON: 

SUBROUTINES  CALLED: 

FUNCTION  DESC RIPTION : 


VREXEC 
VRRMK. FTN 

This  subroutine  extracts  SA  Remarks  and, 
based  upon  Keyword  analysis,  calls 
appropriate  subroutines  for  decoding.  If 
no  Keyword  is  found,  it  then  determines 
whether  the  data  are  free  text  items, 
additive  data  item,  PIREP,  NOTAM,  garbage, 
or  error. 

VREXEC 

Call  VRRMK  (A,  ILEN,  IRMK ,  ALIST ,  IAEND, 
IRKILL,  NWXPASS 

where:  A  *  raw  data  input  array 

ILEN  ■  length  in  bytes  of  raw  data 
array 

IRMK  *  start  position  of  Remarks  in 
raw  data  array 

IRKILL  *  flag  indicating  error  in 
Remarks 

IAEND  *  length  in  bytes  of  translated 
message  in  output  array  ALIST 


RNWY ,  WINDS,  VIS,  SKYRMK,  RNYCND,  PCPMOD, 
WXMOD,  PRES,  LGTNG ,  WETHER 

To  extract  SA  Remarks  and,  based  upon 
Keyword  analysis,  call  the  appropriate 
subroutine  for  decoding. 

Input: 

A  ■  A  byte  array  containing  the  SA 
report  being  decoded. 

ILEN  =  The  length,  in  bytes,  of  the  SA 
report  contained  in  the  array  A. 

IRMK  ■  Points  to  the  beginning  of 
Remarks  in  the  SA  report. 

NWXPASS  ■  A  flag  indicating  if  weather 
data  were  decoded  in  the 
subroutine  VISWX. 

COMMON/CHKLOC/LOC 

where:  LOC  *  A  byte  array  containing 

the  report  location 
identifier 


Output: 

ALIST 


A  byte  array  containing  the 
decoded  SA  report/  including 
Remarks . 

IAEND  *  The  length,  in  bytes,  of  the 
decoded  SA  report  contained 
in  ALIST. 

IRKILL  *  An  error  flag  which  is  set  if 
t±e  Remarks  cannot  be  decoded. 
COMMON/ RSTUFF/RLI ST,  IRNDX ,  NWX 
where:  RLIST  ■  A  byte  array 

containing  the  decoded 
Remarks. 

IRNDX  *  The  current  pointer 
position  within  the 
decoded  Remarks  data. 
NWX  *  A  flag  indicating  if 
weather  data  were 
decoded  in  the 
subroutine  VISWX. 
COMMON/ERROR/ IERROR  (10) 
where:  TERROR  is  an  integer  array 

pointing  to  any  erors 
in  the  SA  report. 
COMMON/ERRPTS/NDXERR,  NDXTEX 
where:  NDXERR*  Number  of  errors  in 

IERROR  array. 

NDXTEX*  Number  of  free  text 
i  terns . 

COMMON/ FRTEXT/FRTEXR  (40),  FRTEXP  (40) 


where: 


FRTEXR  *  An  integer  array 

containing  pointers 
to  free  text  items 
in  the  raw  SA 
repor  t. 

FRTEXP  *  An  integer  array 

containing  pointers 
to  free  text  items 
in  the  decoded  SA 
repor  t. 


COMMENTS: 
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MODULE  NAME: 


VRSSA 


PROGRAM: 
SOURCE  FILE; 
PURPOSE: 


CALLING  ROUTINES: 
CALLING  SEQUENCE: 


COMMON: 

SUBROUTINE  CALLED: 
FUNCTION  DESCRIPTION: 


VREXEC 


VRSSA. FTN 

This  subroutine  receives  a  SA  report  front 
VREXEC  and  determines  whether  or  not  it  is 
a  SA  header  or  a  valid  SA  report.  If  it  is 
a  valid  report,  VRSSA  calls  the  appropriate 
routines  to  decode  it,  and  returns  the 
decoded  SA  (excluding  SA  Remarks)  to 
VREXEC.  It  also  identifies  whether  or  not 
the  SA  is  a  special  and  identifies  the 
position  in  the  report  where  Remarks  begin, 
if  any  exist. 

VREXEC 


call  VRSSA  (ARRAY,  ILEN,  ALIST,  IAEND,  LOC, 
I HEAD ,  IGNORE,  I KILL,  IRMK ,  XWX,  SPCLSA) 
where:  ARRAY  *  raw  data  input  array 

ILEN  *  length  in  bytes  of  raw 
data  array 

ALIST  ■  translated  message  output 


IAEND  * 

LOC  * 
I HEAD  * 

IGNORE  * 

IKILL  =* 
IRMK  * 
XWX  * 

SPCLSA  » 


array 

length  in  bytes  of 
translated  message 
location  identifier 
flag  indicating  whether  or 
not  report  was  a  header 
flag  indicating 
insufficient  data  to 
process 

flag  indicating  error  in 
repor  t 

start  position  of  Remarks 
in  raw  data  array 
flag  indicating  whether  or 
not  report  contained 
weather  data 

flag  indicating  whether  or 
not  report  was  a  Special 
SA. 


EXTHED,  SUBFLD ,  VISWX,  SKY 
Input: 

ARRAY  *  A  byte  array  containing  the 
SA  report  to  be  analyzed. 

ILEN  *  The  length,  in  bytes,  of  the 
SA  report  contained  in  ARRAY. 
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Output: 

ALIST  »  A  byte  array  containing  the 
decoded  SA  report,  not 
including  Remarks  however. 
IAEND  *  The  length,  in  bytes,  of  the 
decoded  SA  report  contained 
in  ALIST. 

LOC  »  A  byte  array  containing  the 
location  identifier  for  the 
SA  report. 

IHEAD  ■  A  flag  which  is  set  if  the 
report  was  a  header. 

IGNORE  *  A  flag  which  is  set  if  there 
were  insufficient  data  to 
process . 

IKILL  *  An  error  flag  which  is  set  if 
the  SA  report  cannot  be 
decoded . 

IRMK  *  Points  to  the  beginning  of 
Remarks  in  the  SA  report. 

XWX  ■  A  flag  indicating  if  weather 
data  were  decoded  in  the 
subroutine  VISWX. 

SPCLSA  *  A  flag  indicating  if  the 
report  was  a  Special  SA. 
COMMON/ ZULU/HTIME,  IRTIM,  STIME 
where:  HTIME  »  A  byte  array 

containing  the  header 
time. 

IRTIM  *  A  byte  array 

containing  the  report 
time. 

STIME  *  A  byte  array 

containing  the  output 
message  time. 
COMMON/ERROR/ IERROR  (10) 
where:  IERROR  is  an  integer  array 

pointing  to  any  errors 
in  the  SA  report. 

C  OMMON/ E  RRPTS / NDXE  RR ,  NDXTEX 
where:  NDXERR  *  Number  of  errors  in 
IERROR  array 

NDXTEX  *  Number  of  free  text 
i  terns . 

COMMON/FRTEXT/FRTEXR  (40),  FRTEXP  (40) 
where:  FRTEXR  *  An  integer  array 

containing  pointers  to 
free  text  items  in  the 
raw  SA  report. 

FRTEXP  »  An  integer  array 

containing  pointers  to 
free  text  items  in  the 
decoded  SA  report. 


COMMENTS: 
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F/6  17/2 


AD-A102  185 


UNCLASSIFIED 


INPUT  OUTPUT  CONPUTER  SERVICES  INC  WALTHAM  MA 
TWENTY-CHANNEL  VOICE  RESPONSE  SYSTEM. (U) 

JUN  81 


FAA-RD-81-51 


DOT-TSC-1313 

NL 


MODULE  NAME; 
PROGRAM; 

SOURCE  FILE: 
PURPOSE; 

CALLING  ROUTINES; 
CALLING  SEQUENCE; 


COMMON; 

SUBROUTINES  CALLED; 
SYSTEM  ROUTINE  REQUIP 
FUNCTION  DESCRIPTION; 


WETHER 

VREXEC 


This  subroutine  decodes  weather  SA  remarks. 
VRRMK 


Call  WETHER  (WORK 
where;  WORD  * 

LN  - 

INDX  - 

LNRMKS  - 

ING  - 


,  LN/  INDX/  LNRMKS,  ING) 
raw  data  word 
length  in  bytes  of  raw 
data  word 

current  index  position  in 
remarks  raw  data  array 
length  in  bytes  of  remarks 
raw  data  array 
flag  indicating  whether  or 


not  a  successful  weather 
decode  occurred. 


# 


# 


None 

:  INUM,  INDSTR 

To  decode  weather  remarks  which  occur  in 

the  Remarks  portion  of  SA  reports. 

Input; 

WORD  »  A  byte  array  containing  the 
data  word  to  be  decoded. 

LN  *  The  length,  in  bytes,  of  the 
data  word 

INDX  »  The  current  pointer  position 
within  the  SA  Remarks  data. 

LNRMKS  *  The  length,  in  bytes,  of  the  SA 
Remarks  data. 

COMMON/RSTUFF/RLIST,  IRNDX,  NWX 
where;  RLIST  *  A  byte  array 

containing  the  decoded 
Remarks. 

IRNDX  •  The  current  pointer 
position  within  the 
decoded  Remarks  data. 

NWX  *  A  flag  indicating  if 
weather  data  were 
decoded  in  the 
subroutine  VISWX. 

Output; 

The  decoded  weather  phrase  is  placed 
into  the  RLIST  array  and  IRNDX  is 
appropriately  incremented. 
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COMMENTS; 


An  error  flag  which  is  set  if 
the  weather  remark  cannot  be 
decoded . 


t 


WINDS 


VREXEC 


This  subroutine  decodes  wind  SA  remarks'. 


VRRMK 


Call  WINDS  (WORD,  LENGTH,  ING,  INDX,  RMK, 
LNRMKS) 

where:  WORK  *  raw  data  word 

LENGTH  *  length  in  bytes  of  raw 
data  word 

ING  *  error  flag 

INDX  *  current  index  position  in 

Remarks  raw  data  array 

RMK  -  raw  REmarks  data  array 

LNRMKS  *  length  in  bytes  of  Remarks 
raw  data  array 

COMMON: 

SUBROUTINES  CALLED:  None 

SYSTEM  ROUTINE  REQUIRED:  INDSTR,  INUM 

FUNCTION  DESCRIPTION:  To  decode  wind  remarks  which  occur  in  the 

Remarks  portion  of  SA  reports. 

Input: 

WORD  -  A  byte  array  containing  the 
data  word  to  be  decoded. 
LENGTH  *  The  length,  in  bytes,  of  the 
data  word. 

INDX  *  The  current  pointer  position 
within  the  SA  Remarks  data. 
RMK  *  A  byte  array  containing  the 
SA  Remarks  data, 

LNRMKS  -  The  length,  in  bytes,  of  the 
SA  Remarks  data. 
COMMON/RSTUFF/RLIST,  IRNDX,  NWX 
where  RLIST  *  A  byte  array  containing 
the  decoded  Remarks 
IRNDX  *  The  current  pointer 
position  within  the 
decoded  Remarks  data. 

NWX  *  A  flag  indicating  if 
weather  data  were 
decoded  in  the 
subroutine  viswx. 

Output: 

The  decoded  wind  phrase  is  placed  into 
the  RLIST  array  and  IRNDX  is 
appropriately  incremented. 

ING  ■  An  error  flag  which  is  set  if 
the  wind  remark  cannot  be 
decoded. 


MODULE  NAME: 
PROGRAM: 

SOURCE  FILE: 
PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 


COMMENTS: 


MODULE  NAME: 


WXMOD 


VREXEC 


This  subroutine  decodes  dispersal  SA 
remarks  such  as  dispersal  schedule  to 
begin/ end  at  (time]  and  dispersal 
began/ended  at  [time]. 

VRRMK 

Call  WXMOD  (WORD,  WLEN,  RMK ,  RLEN,  INDX, 
IERR) 

where:  WORD  *  raw  data  word 


WLEN  ■ 

length  in  bytes  of  raw 
data  word 

RMK  • 

raw  remarks  data  array 

RLEN  » 

length  in  bytes  of  remarks 
raw  data  array 

INDX  - 

current  index  position  in 
remarks  raw  data  array 

IERR  * 

error  flag 

COMMON: 

SUBROUTINES  CALLED:  None 

SYSTEM  ROUTINE  REQUIRED:  INDSTR,  INUM,  I LET 

FUNCTION  DESCRIPTION:  To  decode  dispersal  remarks  which  occur  in 

the  Remarks  portion  of  SA  reports, 
input: 

WORD  *  A  byte  array  containing  the 
data  word  to  be  decoded. 

WLEN  ■  The  length,  in  bytes,  of  the 
data  word. 

RMK  ■  A  byte  array  containing  the  SA 
Remarks  data. 

RLEN  »  The  length,  in  bytes,  of  the  SA 
Remarks  data. 

INDX  ■  The  current  pointer  position 
within  the  SA  Remarks  data. 

COMMON/RSTUFF/RLIST,  IRNDX ,  NWX 

where:  RLIST  »  A  byte  array 


IRNDX  - 

containing  the 
decoded  Remarks 

The  current  pointer 

position  within  the 

• 

decoded  Remarks  data. 

NWX  - 

A  flag  indicating  if 

• 

weather  data  were 

• 

• 

decoded  in  the 
subroutine  VISWX. 

PROGRAM: 

SOURCE  FILE: 
PURPOSE: 

l 

$ 

♦  CALLING  ROUTINES: 

CALLING  SEQUENCE: 
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Ou  tpu  t: 

The  decoded  dispersal  phrase  is  placed 
into  the  RLIST  array  and  IRNDX  is 
appropriately  incremented. 

IERR  ■  An  error  flag  which  is  set  if 
the  dispersal  remark  cannot  be 
decoded . 


I 


® 

A.  3  PDP-11/70  RETREV 


» 

* 


i 


MODULE  NAME 


ASTDMD 


PROGRAM: 

SOURCE  FILE; 
PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 
COMMMON: 


SUBROUTINES  CALLED: 

FUNCTION  DESCRIPTION: 

COMMENTS: 


RETREV 
RE TVER. MAC 

Gets  the  first  M.U  requested  from  Block 
read  into  CSB  ADDS  in  'previous  report"1" 
message  if  report  old 


CSB  PARAMETERS: 

SCRMUT+LMU 
CMU 
BRM.LN 
SBRMIE 
SAB 
$CRBT 
FLAG 
PMAD 
SCRBTPT 

SENDMU 
STIM 

DEMAND  ( DMNDMU  RETDMD . MAC ) 

1.  Input:  RI-CSB  Address. 

2.  Output:  MU  requested  is  put  into 

11/34  send  buffer. 

Must  change  EMT  time  addition  until  system 
value  given  as  Greenwich  mean  time. 


$BKVB 

BLOCK 

.BKHDR 

•MUHDR 

SDIAGB 


MODULE  NAME: 
PROGRAM; 

SOURCE  FILE; 
PURPOSE; 

CALLING  ROUTINES; 
CALLING  SEQUENCE; 
COMMON; 


SUBROUTINES  CALLED; 
FUNCTION  DESCRI PTI ON : 


COMMENTS; 


ASTVER 
RETREY 
RE  TVER. MAC 

Subroutine  to  verify  requested  loc  from  lit 
block  -  set  report's  available  mask 

RDAST 

The  AST  address  after  a  read  complete 

CSB  PARAMETERS: 

SLOCPTR 

LOCSIZ 

$CRMUT  +  LMU  (Rl)  (used  as  count  of  Iocs 

at  this  pt  must  be  less 
than  10) 

BRM.ER 
SBRIME . 

UDBAS 
SBKBV 


Address  of  CSB  -  Rl. 
location  verification  -  @ 
sign  replaces  proper  loc 
repor  t  mask  - . 
bits  set  for  report  types 
available.  Buffer  sent  to 
last  loc  -  next  read  issued 
if  not. 


SAB 

.UDMOD 

SRPMSK 

SDIAGP 


1.  Input: 

2.  Output: 


RPMSK  - 
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MODULE  NAME: 
PROGRAM; 

SOURCE  FILE; 
PURPOSE; 

CALLING  ROUTINES; 
CALLING  SEQUENCE; 
COMMON: 


SUBROUTINES  CALLED: 

FUNCTION  DESCRIPTION: 


COMMENTS: 


BRF  2 
RET REV 
RETBRF 

Process  11/34  Briefing  Request  #2;  Build  a 
Channel  Response  Briefing  Table  (CRBT)  of 
Blocks  fo'r  each  report  per  location 
requested;  send  request  accepted  or  error 
w/request  acknowledgment  back  to  11/34. 


SUSPEN  (RETMAN .MAC) 

CSB  PARAMETERS: 

$BRMIE 

SCRMUT 

LMU 

GMU 

$DIAGB 

$DIAGP 

$CRBT 

SCRBTPT 

SHOURS 


SALT 

SLOST 

JRLOCS 

FLAG,  BLOCK,  MUNUM 

SSAVCB 

LOCSIZ 

SOB 

FREEPL  -  free  pool 
(of  buffers) 
list  head 


FDBLK 

SEND 

System:  CDTB  convert  data  to  binary  BSDRSS 


1.  Input:  Briefing  Request  #2  from  11/34 

x  F  /F  /F  -n  -n  cr 
12  3  12 

x  »  Channel  # 

FI  ■  report  type  IF  »  FD 

3 

request,  n  »  hours,  n  alt 
1  2 

2.  Output:  CRBT  the  FLAG  bits  for  SKIP 

type,  start  of  report  type, 
the  BLOCK  containing  report 
requested  for  loc;  the 
message  unit  no.  slot  (only 
1st  filled  in) .  These  three 
words  (FLAG,  BLOCK,  MUNIM) 
are  filled  for  each  loc  per 
report  block  requested. 

Rl  -  CSB  address 

R3  -  input  buffer  address 


i 


, 
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MODULE  NAME: 
PROGRAM: 

SOURCE  FILE: 
PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 

COMMON: 


SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 

COMMENTS: 


DBLOCK 
RET  REV 
RETSUB.MAC 

Decrement  map  for  all  report  blocks  listed 
in  previous  briefing  table  for  channel  then 
clears  out  the  RLOCS  table. 


SUSPEN  (RETMAN.MAC) 

DEMAND  (RETDMD.MAC) 

CSB  Parameters: 

SCRBT 
BLOCK 
SLSTLOC 
$ RLOCS 

. NUM  No.  of  report  types 
ISA  SA  offset 

FDBLK 

1.  input  R1  -  CSB  Address. 

2.  Output  Map  decremented  for  each  olock 

in  RLOCS  table  RLOCS  table 
cleared. 
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MODULE  NAME; 


DEMAND 


PROGRAM: 

SOURCE  FILE: 
PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 

COMMON: 


SUBROUTINES  CALLED: 


FUNCTION  DESCRIPTION: 


RET REV 
RETDMD . MAC 

Process  all  11/34  demands  for  message  unit 
data 


SUSPEN:  ( RETMAN . MAC )  -  after  1st  input 
buffer  character  is  decoded  as 
a  demand  directive 


ASTDMD: 

(send  to  DMNDMU)  RETREV . MAC 

CSB  PARAMETERS: 

$QB 

SSTAG 

SDIAGB 

$BKVB 

DIAGP 

SCRBTPT 

$CRBT 

GMU 

BLOCK 

LMU 

ERR. DM 

MUNUM 

SIOST 

$MURQ 

BRM.CE 

CRBTSZ 

SBRMIE 

FLAG 

GETCSB 

SYSTEM  ROUTINES 

QUEUE 

READ 

SUSPEN 

$CDTB- ASCI I -to- BINARY  conversion 

DBLOCK 

$CBDMG- Binary- to  ASCII  conversion 

SENDMU 

SCBDSG- Binary- to  signed  decimal 
magnitude 

1.  input:  Input  buffer  address. 

2.  Output:  Check  buffer  for  channel  number 

and  demand  type  key: 

A.  Hang  up  demand, 

B.  Send  message  unit, 

C.  'jump  ahead'  to  message 
unit  and  send, 

D.  repeat  message  unit  demand. 

A.  Decrements  map  values  and 
returns  to  11/34  hangup 
acknowledge  'A'. 

B.  If  message  unit  requested 
in  core  -  send  1)  channel 
#,  2)  B-demand  type,  3) 
message  unit  data;  if 
message  unit  not  in  core, 
proper  block  is  read, 

(AST)  the  stage  indicator 
is  set  to  1,  and  message 
is  requeued  until  read 
completed. 
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C.  Checks  if  HU  requested 
~  less  than  least  message 

unit  (LMU)  in  core,  output 
same  as  for  B  -  demand. 

If  MU  requested  greater  or 
equal,  then  skip  ahead 
flag  is  checked,  link  flag 
checked  and  proper  block 
read . 

D.  Back-up  in  CRBT  to  proper 
~  block  requested  and  block 

read  (AST) ,  message 
requested,  stage  indicator 
set  to  1. 

Any  error  in  format  of  demand  from  11/34  is 
sent  back  with  error  diagnostic  (ERRTN) . 


MODULE  NAME: 

PROGRAM: 

SOURCE  PILE: 

PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 

COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 


DQUEUE 
RETREV 
RETSUB . MAC 

DEQUEUES  an  element  from  the  CSB  QUEUE 
list-head. 


RETINI  (MAC) 

SUSPEN  -  ( RETMAN . MAC ) 

TINAST  ( RET AST . MAC ) 

None 

None 

1.  Input:  R3-CSB-QUEUE  hold  location. 

2.  Output:  R3-CSB  QUEUE  address  which  now 

holds  the  next  QUEUE  link  -  it 
no  more  QUEUE  elements  CSB  head 
and  tail  QUEUE  list  head  is  zero 
R4-QUEUE  address  link. 

Sets  carry  bit  if  no  elements 
QUEUED  on  list  head. 


COMMENTS: 


MODULE  NAME: 
PROGRAM : 

SOURCE  PILE: 
PURPOSE 8 

CALLING  ROUTINES: 
CALLING  SEQUENCE; 


COMMON; 

SUBROUTINES  CALLED; 
FUNCTION  DESCRIPTION; 


ERRTN 
RETREV 
RETDMD . MAC 

Routine  for  processing  error  conditions 


DEMAND  (RETDMD. MAC) 
RETINI  -  (RETINI .MAC) 
RDAST  -  (RETAST.MAC) 
TINAST  (RETAST.MAC) 


Send  system  $CBDMG.  Binary  to  ASCII  decimal 
magnitude 


1. 

Input: 

Rl  -  CSB  address 

R4  -  Error  code  buffer 

RS  -  Error  code  number. 

2. 

Output: 

RO  -  address  of  translation  of 
error  code. 

COMMENTS; 
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MODULE  NAME: 

EXIT 

PROGRAM: 

RETREV 

SOURCE  PILE: 

RETMAN . MAC 

PURPOSE: 

Performs  retrieval  exit  tasks 

CALLING  ROUTINES: 

1 

CALLING  SEQUENCE: 

SUSPEN  -  if  exit  flag  has  been  set  by 

TINPUT  upon  receiving  11/34  exit  directive 
RETINI  -  if  error  opening  or  reading  UDF 

file 

COMMON: 

.LINE  -  CSB  parameter 

INPFDB  -  UDF- DAT  file  descriptor  block 

SUBROUTINES  CALLED: 

GETCSB  -  get  CSB  address 

DBLOCK  -  free  blocks  in  RLOCS 

FDBLK  -  free  block  allocate  for  winds. 

Data  in  CRBT  -  channel  response 
block  table 

TINPUT  -  detach  terminal  directive 

FUNCTION  DESCRIPTION: 

1.  input:  None  required. 

2.  Output:  1)  A  send  directive  to 

1 FDRTRV '  task  to  exit. 

.  : 

2)  Map  decremented  to  free 

report  blocks  for  all 

* 

channels . 

r 

3)  Close  UDF. DAT  file- 

•  | 

4)  Cancel  all  mark- time 

requests. 

1 

•  i 

COMMENTS: 

5)  Detach  terminal. 

.  1 

i 

1 

1 
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MODULE  NAME: 

PROGRAM: 

SOPRCE  FILE: 

PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 

COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 


PDBLK 
RET REV 
RETBRF.MAC 

To  decrement  map  values  £oc  FD  -  winds  data 
blocks  in  the  CRBT 


EXIT  (RgTMAN.MAC) 

DBLOCK  (RETSUB.MAC) 

BRF2  (RETBRF.MAC) 

CSB  Parameters 

$CRBT 

BLOCK 

FLAG 

CRBTSZ 

None 

1.  Input:  Rl  -  CSB  Address* 

2.  Ouptut:  Map  values  corresponding  to  FD 

Blocks  in  CRBT  are  decremented. 


COMMENTS 


MODULE  NAME: 
PROGRAM; 


GETCSB 


RETREV 
RETSUB .MAC 

Translates  binary  or  ASCII  channel  number 
to  its  channel  status  block  address 


SOURCE  FILE: 

PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 

COMMON; 

SUBROUTINES  CALLED; 
FUNCTION  DESCRIPTION; 


RETINI .MAC 
SUSPEN  ( RETMAN . MAC ) 
EXIT  {RETMAN. MAC) 
DEMAND  ( RETDMD . MAC ) 

None 

None 


RCVAST  (RETAST.MAC) 
TINAST  (RETAST.MAC) 


1.  Input:  Rl  -  the  binary  or  ASCII 

channel  #. 

2.  Output:  Rl  >  the  CSB  address. 

Rl  is  reserved  throughout  RETREV  to  hold 
this  CSB  address,  (unless  it  must  be 
changed  when  calling  a  system  routine 
requiring  Rl) . 


COMMENTS; 


MODULE  NAME 


MRKAST 


PROGRAM; 
SOURCE  FILE; 
PURPOSE; 


CALLING  ROUTINES; 
CALLING  SEQUENCE: 

COMMON; 

SUBROUTINES  CALLED; 
FUNCTION  DESCRIPTION: 

COMMENTS; 


RETREV 
RETAST . MAC 

Set  timer  to  check  for  data  received  for 
FDRTRV  (this  is  a  precautionary  measure  to 
insure  all  sends  from  FDRTRV  are  received 
since  there  are  some  11/70  system  problems 
with  the  receive  AST  logic) 


System  traps  to  this  routine  when  the  mark 
time  elapses 

MARK  FLAG 

RCVAST 

1.  Input:  None. 

2.  Output:  Resets  new  mark  time. 

Uses  mark  time  AST  routines  MRKT$S  to 
continuously  check  for  data  received  from 
•FDRTRV' . 


i 


i 

£ 
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MODULE  NAME; 

PRO RAM: 

SOURCE  FILE: 

PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 

COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 

COMMENTS: 


OUTSEND 
RET  REV 
RETBRF.MAC 

Perform  check  sum  logic  on  buffer  to  be  sent 
to  11/34  and  QUEUE  the  buffer  to  be  sent 


SEND 

SENDMU 


(RETBRF.MAC) 

(RETBRF.MAC) 


$IOST  -  CSB  parameter 
TINPUT 


1.  Input:  R2  -  Buffer  address  for  data  to 

be  sent. 

2.  Output:  Performs  check  sum  logic  and 

adds  check  sum  characters  to 
output  buffer. 

Outsend  kills  any  pending  reads  to  the 
terminal,  then  outputs  the  buffer.  A 
terminal  read  is  then  reissued  in  order  to 
receive  input  continuously.  The  checksum 
logic  is  as  follows: 

EXAMPLE: 


CR 


A) 


• 

•  j 

m  | 

46 

101 

*  j 

15 

buffer 


46 


101 


15 


164 


B) 


output  buffer 
with  check  sum 
charac ters 

Figure  A  is  the  initial  output  buffer,  with 
each  character  inserted  at  a  byte  location. 
The  output  buffer  is  an  acknowledge  of  a 
hangup  demand  to  11/34.  The  check  sum  logic 
then  appends  the  two  null  characters,  the 
binary  sum  of  the  characters,  followed  by 
the  number  of  characters  sent,  including  the 
check  sum  characters  -  as  shown  in  Example  B. 
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MODPLB  NAME: 

PROGRAM; 

SOURCE  FILE: 

PURPOSE: 

CALLING  SEQUENCE: 

COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 


COMMENTS: 


QUEUE 

RETREV 

RETSUB . MAC 

Add  buffer  to  QUEUE 

SUSPEN  (RETMAN .MAC) 

DEMAND  (RETDMD.MAC) 

TINAST  (RETAST.MAC) 

None 

None 

1.  input:  R3  -  QUEUE  list  head  address  - 

(QUEUE  head  &  tail  pointer) 

R4  -  $QB  (Rl)  the  buffer  address 
R1  -  the  CSB  address. 

2.  Output:  The  QUEUE  tail  pointer  updated 

to  addition  of  buffer  QUEUED 
the  last  buffer  tail  pointer 
changed  to  point  to  added  buffer. 
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MODULE  NAME: 
PROGRAM: 

SOURCE  FILE: 
PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 


COMMON: 


SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 


COMMENTS: 


RCVAST 
RETREV 
RETAST . MAC 

AST  location  for  data  received  from  11/70 
programs  currently  (9/1/78)  only  from  FDRTRV 


RCVAST  is  trap  location  for  data  received 
from  11/70  programs  FDRTRV  but  is  also 
called  by  MRKAST.  (RETAST. MAC) 

CSB  parameters 

SBRMIE 

JSAVCB 

BLOCK 

CRBTSZ 

SDIAGB 

FLAG 

SEND  GETSSB 

1.  Input:  Data  block  of  4  words  queued  by 

11/70  program  FDRTRV  word 

1  RAD50  'FDR' 

2  RAD  50  'TRV '  name  of  sender 

3  Channel  #  task 

4  Block  #  of  FD  report 
requested  by  RETREV. 

2.  Output:  Fills  block  #  received  into 

CRBT  BLOCK  LOC  as  pointed  to  by 
$SAVCB 

if  1st  FDBLOCK  received,  then 
the  output  buffer  containing 
acknowledge  to  11/34  is  sent- 


A- 170 


A 
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MODULE  NAME: 

PROGRAM: 

SOURCE  PILE: 

PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 
COMMON: 

SUBROUTINES  CALLED: 

FUNCTION  DESCRIPTION: 


RDAST 
RET  REV 
RETAST.MAC 

The  AST  address  after  a  read  completes,  the 
program  vectors  either  for  an  LIT  read  for 
LOC  verification  or  an  UDF  report  block 
read  for  message  units. 


AST  address  after  a  read  on  UDF  completes 

CSB  parameters: 

SIOST 
$ STAGE 

ERRTN  ASTSRP 

ASTVER 

ASTDMD 

1.  Input:  SP  contains  #  characters 
transferred  on  read  and  the  10  status 
word  in  CSB. 

2.  Output:  vectors  program  to  either 
ASTVER  -  verify  LOC  IDS 

ASTDMO  -  DEMAND  request 

ASTSKP  -  skip  to  next  briefing  block. 


COMMENTS 


MODULE  NAME: 
PROGRAM: 

SOURCE  FILE: 
PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 
COMMON: 


FUNCTION  DESCRIPTION: 
COMMENTS: 


Retrieval  Constant  Area 
RET REV 
RETCON . MAC 

Storage  area  for  retrieval  program 


All  routine  use  the  area 
The  storage  areas  are: 

19:  Channel  Status  Blocks  -  a  block  for 
each  channel  line  the  block  is  described  in 
template  file  prefix. max  (3200  bytes  -  size 
per  CSB) 

75600  -  Freepool  list  head 
75602  -  Freepool  buffers  -  (41  buffers) 
Free  1  -  Free  41 
Each  buffer  has  link  pointer  1 
word  plus  25  words 

101730  -  return  QUEUE  list  head  (head  & 
tail  pointer  two  words) 

101736  -  IO  QUEUE  list  head 

101740  -  INPFDB  -  UDF  file  descriptor  block 


I 
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MODULE  NAME: 
PROGRAM: 

SOURCE  FILE; 
PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 

COMMON: 


SUBROUTINES  CALLED: 

FUNCTION  DESCRIPTION: 


COMMENTS: 


RETIN I .MAC 
RETREV 


Initialization  module  for  program  RETREV 


The  VRS  11/34  logs  onto  the  11/70  and  runs 
RETREV  the  start  address  for  RETREV  IS  AT 
BEGINNING  OF  RETINI 

Channel  status  block  parameters 
SBKVB  MRKAST  -  Mark  time  AST  address 

LOCSIZ  TINPUT  -  Terminal  QIO  address 

. BLKHD  FREEPL  -  Free  pool  list  head 
SCSBIN  TINAST  -  Terminal  input  AST  address 
SEVMSK 

INPFDB  -  File  Descriptor  Block  UDF  address 
CSBADR  -  Channel  status  block 
PMAD  -  'previous  message'  address 
RCVAST  -  receive  AST  address 

EXIT  SYSTEM  ROUTINES: 

ERRTN  WAIT  FINIT  QIO 

GETCSB  SRDA$$  OPNSJM  READ 

1}  Opens  UDF. DAT. 

2)  Gets  'previous  report'  messasge  from 
block  number  given  at  zero  loc  in  UDF 
LIT,  stores  the  messagae  for  future 
use  at  global  address  PMAD. 

3)  Sets  receive  AST  address. 

4)  Attaches  terminal  for  RETREV  task. 

5)  Issues  another  terminal  read- 

6)  Jumps  to  suspend  address  in  main  body 
code  of  RETMAN 

The  channel  status  block  offsets  are 
defined  in  the  prefix  file  RETINI. MAC,  each 
module  of  RETREV  must  be  compiled  with  this 
module . 
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MODULE  NAME; 

PROGRAM; 

SOURCE  PILE; 

PURPOSE; 

CALLING  ROUTINES; 
CALLING  SEQUENCE; 
COMMON; 

SUBROUTINES  CALLED; 
FUNCTION  DESCRIPTION; 


RETURN 
11/34  VRS. 

BACKGR . MAC 

Routine  to  return  address 
specified  in  US.RTN 


All  FL. *** 

US.*** 

TR.*** 

TRAP  TR-QUE 

1.  If  echo-done  bit  is  set,  return  one 
element  to  RDQUE. 

2.  In  any  case,  restore  R1  from  US.SAl. 

3.  Jumps  to  address  specified  in  US.RTN 
of  USB. 


COMMENTS 


MODULE  NAME: 


SEND 


PROGRAM: 

SOURCE  FILE: 
PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 


COMMON: 


SUBROUTINES  CALLED: 

FUNCTION  DESCRIPTION : 


RETREV 
RETBRF . MAC 

Count  number  of  characters  in  buffer  - 
insert  two  null  characters  insert  character 
count  and  buffer  address  into  QIO  block 


RCVAST  ( RET AST . MAC ) 

ERRTN  (RETDMD.MAC) 

BRF  2  (RETBRF. MAC) 

Output: 

address  of  QlO  parameter  block  for 
output  to  11/34 

(Output  -  QIO$  Output)  System:  IOKILL  - 
kill  any  pending  I/O  to  terminal  OUTSND 

1.  Input:  Rl ,  CSB  address 

R2,  the  output  buffer  address. 

2.  Output:  The  character  count  and  buffer 

address  in  the  Q  0  output  block* 


COMMENTS: 


MODULE  NAME: 


SENDMU 


PROGRAM: 
SOURCE  FILE: 
PURPOSE: 


CALLING  ROUTINES: 
CALLING  SEQUENCE; 

COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 


RETREV 

RETBRF.MAC 

1)  Compute  end-of-send  buffer  (without 
two  null  terminator)  then 

2)  Call"  outsend  to  perform  check  sum  and 
I/O  to  11/34 


BRF2  (RETBRF.MAC) 

ASTDMD.  (RETVER.MAC) 

DEMAND  ( RETDMD . MAC ) 

Output  -  Address  of  QIO  request  block 
Output  -  QIO  for  output  to  11/34 

1.  Input:  R2  -  output  buffer  address 

R3  -  no  of  characters  to  send. 

2.  Output:  the  output  buffer  with  check 

sum  characters  to  be  sent  by 
11/34- 


COMMENTS 


MODULE  NAME; 


SNDAST 


PROGRAM: 

SOURCE  FILE: 

PURPOSE : 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 

COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 


COMMENTS: 


RET REV 
RETAST.MAC 

Send  AST  address  to  resume  RETREVAL,  and 
queue  next  event  for  channel 


11/70  system  traps  to  this  address  after  an 
11/70  -  11/34  send  completes 

CSB  parameters: 

SIOST 

BRM.BY 

SBRMIE 

SEVNSK 

EVENT  -  event  word  for  channel  activity  bit 
flags 


1.  Input:  10  status  block  from  stack 

pointer  (computes  CSB  from 
SlOST  wordy, 

2.  Output:  Event  word  with  bit  set  for 

appropriate  channel  busy 
cleared  in  the  channel  busy 
word  SBRMIE. 


MODULE  NAME: 


SUSPEN 


PROGRAM: 

SOURCE  FILE: 

PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE; 

COMMON: 

SUBROUTINES  CALLED: 

FUNCTION  DESCRIPTION: 
COMMENTS: 


RETREV 
RETMAN . MAC 

Check  event  flag  for  channel  activity  if 
yes  jump  to  briefing  request  routines  or 
demand  processing  if  not  suspend 


The  initialization  module  calls  suspend 
initially,  after  that  it  is  the  suspend 
address  called  after  each  channel  activity 
has  been  completed.  Demand  (RETMAN. MAC) 


Channel  status  block  parameters: 


SDIAGB 

SEVMSK 

$QB 

SRLOCS 
EVENT  - 


BRM.BY  $MOD£ 

. UDMOD  SQUEUE 
$BKVB  SRPMSK 
SLOCSPTR  BRM.ER 


SBRMIE 
. UDBAS 
$STAGE 


double  word  containing  bits  set 


for  each  channel  to  be  serviced 


FREEPL-  address  of  free  pool  list  head 
(head  &  tail  pointer) 


GETCSB  DEMAND  QUEUE  SYSTEM  ROUTINES 

DQUEUE  DBLOCK  SCATS 


Inhibits  AST  processing  while  checking 
event  flags  and  dequeueing  an  element. 


MODULE  NAME : 
PROGRAM: 

SOURCE  FILE: 
PURPOSE: 

CALLING  ROUTINES; 
CALLING  SEQUENCE: 

COMMON: 


1 


TINAST 

RETREV 

RETAST.MAC 

AST  address  for  terminal  read  complete 


AST  address  upon  terminal  input  received 
from  11/34 

CSB  paramenters: 

SQUBUE 

FREEPL 

SEVMSK 

Event  -  word  of  channel  activity  bit  flags 
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SUBROUTINES  CALLED; 

FUNCTION  DESCRIPTION: 


COMMENTS: 


Exit  FL  »  flag  word  for  exit  directive 

RSUM$  RET REV  GETCSB 

QUEUE  DQUEUE  ERRTN 

1.  Input:  Buffer  queued  to  terminal  by 

11/34 

2.  Output:  1.  DEQUEUES  buffers  for 

particular  channel  if 
receive  is  a  hang  up 
directive 

2.  Sets  exit  flag  if  receive 
is  an  exit  directive 

3.  Issues  next  terminal 
receive  for  continuous 
terminal  input. 

TINAST  performs  check  sum  logic  on  receive 
data  and  checks  it  against  the  received 
11/34  check  sum  characters  (see  outsend 
module  for  description  of  check' sum  logic). 
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A. 4  POP-1 1/70®  VRSOOT 
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MODULE  NAME: 


BLCR8 


PROGRAM:  VRSOUT 

SOURCE  FILE :  BLCR8 . FTN 

PURPOSE:  To  format  the  report  into  message  unit 

block  format 


CALLING  ROUTINES:  VRSOUT 

CALLING  SEQUENCE:  BLCR8  (ITIM,  NMUS,  PDICO,  IPNDX,  IPAIRS, 

IFILE ,  BLOCK) 


COMMON:  ITIM  - 

NMS  - 
PLICO  - 

IPNDX  - 

IPAIRS  - 
I FITE  - 
BLOCK  - 


time  of  report 

number  of  message  units  in  Block 
start  address  of  the  report  in 
common 

pointer  to  the  report  array 
PDICO 

number  of  PTR  pairs  in  block 
report  type  subfile  number 
the  Block  Buffer 


SUBROUTINES  CALLED:  None 

FUNCTION  DESCRIPTION:  1.  Input:  The  offset  in  the  ARRAY  PDICO 

to  the  format  into  block  format. 

2.  Output:  The  report  pointers  in  block 
format  that  is  4  message  unit 
headers  followed  by  the  message 
unit  of  27  pointer  pairs. 


COMMENTS: 


MODAL E  NAME 


IOBLCK 


PROGRAMS 
SPARGE  PILE: 
PARPOSE: 


VRSOAT 
IOBLCK. FTN 

To  read/write  data  to  ADF.DAT 


CALLING  RQATINES: 
CALLING  SBQAENCE: 
COMMON: 


SABROATINES  CALLED; 
FUNCTION  DESCRIPTION: 


VRSOAT 

CALL  IOBLCK  (FANC,  BLMVM,  BLCK) 

FANC  -  the  function  to  perform 

1  *  Read 

2  »  Write 

BLNAM  -  Block  number  to  be  written 
8LCK  -  the  buffer  to  receive  the  block 
read  or  to  be  written  in  the 
ADF.DAT  depending  on  the  function 
requested 

System  Routines  :  Read  -  Write 

1.  Input:  Block  number  function  to 

perform  buffer  for  block. 

2.  Output:  The  block  to  ADF.  or  the  block 

read  into  buffer  an  error  flag 
is  returned  in  the  function 
parameter  -  FUNC. 


COMMENTS: 
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MODULE  NAME 


NOTAVB 


PROGRAM: 

SOURCE  FILE: 
PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 


COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 


COMMENTS: 


VRSOUT 
NOTAVB. FTN 


VRSPURG 

Call  NOTAVB  (LOC ,  IFILE,  NOTBLK) 
where  LOC  »  location  identifier 

IPILE  »  1  value  for  SA  purge,  2 

value  for  FT  purge 
NOTBLK  *  block  number  where  the 
purge  message  was 
written  in  the  UDF 


BLCR8,  IOBLCK,  ACTIV,  DICT 

This  subroutine  inserts  a  "Report  Not 
Available"  message  for  a  given  locid  SA  or 
FT  report  into  the  UDF  and  returns  the 
block  number  where  it  was  written  to  the 
calling  program,  VRSPURG,  for  insertion  in 
the  LIT. 
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MODULE  NAME: 


SASPEC 


PROGRAM: 

SOORCE  PILE: 
PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 

COMMON: 


SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 


COMMENTS: 


VRSOUT 
SASPEC. FTN 

To  append  SA  specials  to  the  SA  report  for 
the  sane  hour 

VRSOUT 


Call  SASPEC  (MAP,  HDDR,  KB,  PDICO,  NP, 
IOLD,  1TIM) 


MAP  - 

HDDR  - 

KB  - 

PDICO  - 
IOLD  « 

NP  - 
ITIM  « 

None 


the  address  of  the  (global  common) 
amp  array 

buffer  containing  first  block  of 
current  report 

the  first  free  block  available 

(for  ichain  value) 

the  report  array 

the  UDF  block  number  of  current 

report 

the  number  of  PTR  pairs  in  report 
the  report  time 


1.  Input:  The  3A  special  report. 

2.  Output:  The  report  appended  to  the 

current  SA  report,  the 
remaining  report  is  returned 
to  VRSOUT  for  regular 
processing  by  BLCR8  -  and 
IOBLCK . 

If  a  report  currently  contains  an  appended 
report,  the  time  is  checked,  if  the  new 
report  is  more  recent  it  is  written  over 
the  old  special,  and  any  remaining  linked 
blocks  are  freed  -  (map  value  decremented) . 
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MODULE  NAME: 


VRSOUT 


PROGRAM: 

SOURCE  PILE: 
PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 

COMMON: 


SUBROUTINES  CALLED: 

FUNCTION  DESCRIPTION? 


COMMENTS: 


VRSOUT 
VRSOUT. FTN 

Receives  directive  from  VRS  (processor 
executive)  to  output  data  to  UDF.DAT  file 


VRSOUT  is  an  installed  task  which  is  loaded 
into  memory  upon  initial 
send/request/resume  directive  from 
VRS. VRSOUT  then  remains  suspended  until  it 
receives  an  exit  directive. 

VRS  global  common  area 
MAP  -  index  to  UDR  b_ock  usage 
PDTCN  -  processed  .  _;port  array  (ASSCII) 
PDICO  -  trans.  .ed  report  array  (integer 
ptrs) 

ATADII  -  winds  data  (raw) 

ATADIO  -  winds  data  (translated) 

SEND  BLOCK  RECSND/R 

Rl  sender  name  in  RAD50 

R2  -  sender  name  in  RAD50 

R3  -  Report  type 

R4  -  LOC-in  RAD50 

R5  -  Translated  pairs 

R6  -  PDICIN  length 

R7  -  Date  (day  of  month  in  ASCII) 

R8  -  Date 

R9  -  Time  (time  -  HH-MN  in  ASCI) 

RIO-  Time 
Rll-  Time 
R12-  Time 

BLCR8 

LOBLCK 

SASPEC 

1.  Input:  The  received  send-block  R16 

integers  the  report  to  output 
in  PDICO. 

2.  Output:  The  report  in  block  format 

chained  to  addition  blocks  is 
necessary  and  output  to  UDF- 

VRSOUT  is  an  installed  task  installed  by 
VRSINS.CMD. 
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MODULE  NAME: 


VRSPURG 


PROGRAM: 

SOURCE  PILE: 

PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 
COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 

COMMENTS: 


VRSOUT 
VRSPURG. PTN 


VRSOUT 
Call  VRSPURG 


ZULUTM,  VDATE,  R50ASC ,  NOTAVB ,  ACTIV,  DICT 

This  subroutine  purges  from  the  UDP  those 
SA  reports  which  are  more  than  2  hours  old 
and  those  FT  reports  that  are  more  than  8 
hours  old. 
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A. 5  PDP-11/70®  VRSFD 


MODULE  NAME 


VRSFD  (installed  task) 


PROGRAM;  VRSFD 

SOURCE  FILE;  VRSFD. FTN 

PURPOSE;  This  program  retrieves  and  processes  winds 

Aloft  data  from  the  KCW.DAT  file  and  stores 
it,  according  to  a  record  number 
calculation,  in  the  UDF  for  later  VRS 
retrieval  by  FDRTRV. 

CALLING  ROUTINES;  VREXEC 

CALLING  SEQUENCE;  Called  through  ACTIV 

COMMON; 

SUBROUTINES  CALLED:  GTRPT ,  IDATE,  IOBLCK,  EXTSTR,  RECEV 

FUNCTION  DESCRIPTION;  To  extract  Winds  Aloft  data  from  the 

KCW.DAT  file  and  process  and  store  it  in 
the  UDF  for  later  VRS  retrieval  by  FDRTRV. 
Input: 

PAR  ■*  A  7  integer  array  passed  in  the 
ACTIV  send  block  containing  the 
KCW.DAT  file  pointers  for  winds 
Aloft. 

Output: 

None 

COMMENTS: 
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A. 6  PDP-11/70®  PDRTRV 
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MODULE  NAME: 


PROGRAM; 

SOURCE  FILE: 

PURPOSE ; 

CALLING  ROUTINES; 
CALLING  SEQUENCE; 
COMMON; 

SUBROUTINES  CALLED; 

FUNCTION  DESCRIPTION: 


FDRTRV  (installed  task) 

FDRTRV 
FDRTRV . FTN 

To  retrieve  ATA  winds  data  requested  by 
RET REV. 

RETREV 

Called  through  ACTIV 


R50ASC ,  I DATE,  TIME,  IOBLCK,  SUMMIT,  RECEV, 
ACTIV,  BLCR8,  VRECEX,  DICT,  RETREV 

This  program  is  activated  upon  a  Winds 
Aloft  request  from  RETREV.  Data  received 
from  RETREV  consist  of  the  channel  number 
of  the  request,  altitude  requested,  number 
of  hours  to  departure,  RAD50  representation 
of  the  locid,  latitude  and  longitude  of  the 
locid.  The  program  then  determines  the 
appropriate  data  to  obtain  from  the  UDF, 
interpolates  the  data,  and  creates  a  voice 
response  message  containing  the  decoded 
results,  it  then  stores  the  message  in  the 
UDF  and  returns  to  RETREV  the  block  number 
where  it  was  stored  as  well  as  the  channel 
number  of  the  request. 

Input: 

R»A16  integer  word  array  passed  in 
RECEV  where: 

R ( 4 )  *  channel  number 
R (5 )  *  altitude 

R(6)  ®  number  of  hours  to  departure 
R (7 )  »  RAD50  locid 
R(8 )  *  latitude 
R(9)  *  longitude 

COMMON/VRSGLB/MAP  (10240),  PDICIN 
(700),  PDICO  (350)  AT AD I I  (160), 

ATADIO  (160) 

where:  MAP  =»  A  byte  array 

representing  the  status 
of  the  UDF. 

PDICIN  ■  A  byte  array 

containing  dictionary 
input  from  VRSINP. 

PDICO  »  An  integer  array 

containing  dictionary 
output  corresponding 
to  PDICIN. 
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w 


4 

4 

COMMENTS: 


Ou  tpu  t: 


ATADII 

ATAOIO 


■  A  byte  array 
containing  dictionary 
input  from  PDRTRV. 

*  An  integer  array 
containing  dictionary 
output  correspondina 
to  ATADII. 


- ^ 


ACTIV 

where:  R(4)  ■  channel  number 

mifi  “  Wfnds  Aloft  response 
message  location  in  UDF. 
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MODULE  NAME 


IOBLCK 


PROGRAM: 

SOURCE  FILE: 
PURPOSE: 

CALLING  ROUTINES: 


CALLING  SEQUENCE: 
COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 


COMMENTS: 


FDRTRV ,  VRSOUT 
IOBLCK.FTN 

This  subroutine  reads  or  writes  a  block  of 
data  from  or  into  the  UDF. 

Call  IOBLCK  (FUNC,  BLNUM,  BLCK) 

where:  FUNC  ■  1  for  read  operation,  2 

for  write  operation 
BLNUM  *  block  number  of  data  to  be 
read  or  written 
BLCK  >  data  block 

None 


This  subroutine  reads  or  writes  a  block  of 
data  from  or  into  the  UDF. 

Input: 

FUNC  *  1  for  a  read  operation,  2  for  a 
write  operation 

BLNUM  »  Block  number  of  data  to  be 

read  or  written  • 

BLCK  »  Data  block  to  be  written. 

Ou  tpu  t: 

BLCK  •  Data  block  read. 


ft 

ft 
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MODULE  NAME: 
PROGRAM: 

SOURCE  FILE: 
PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 


COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 


SUMMIT 


FDRTRV 


SUMMIT. FTN 

Interpolate  Winds  Aloft  data  for  a 
requested  geographical  position. 

FDRTRV 


Call  SUMMIT  (LVL,  NDAT ,  SUMT,  SUMX,  SUMY, 
MASTER) 


where:  LVL  ■ 

NDAT  » 
SUMT  » 
SUMX  * 
SUMY  ■ 
MASTER  * 


data  level  required  (1,  2 
or  3  value) 

pressure  level  required 
within  data  level 
interpolated  temperature 
value 

interpolated  X  coordinate 
value  of  the  wind  vector 
interpolated  Y  coordinate 
value  of  the  wind  vector 
UDF  record  9972  containing 
special  flag  and  time 
values  for  diagnosing 
invalid  data. 


I08LCK,  WTF0R3 

This  subroutine  retrieves  wind  Aloft  data 
for  the  data  level,  blocks,  and  subsquares 
given  in  the  calling  statement  and  FDSUM 
labeled  common.  It  then  interpolates  the 
data  for  the  geographical  point  requested 
according  to  calculated  weighting  factors 
and  returns  the  results  to  the  calling 
program  FDRTRV. 

Input: 

LVL  *  Winds  Aloft  data  level 

required  (1,  2  or  3  valve) 
NDAT  -  Pressure  level  required 
within  the  data  level. 

MASTER  *  UDF  record  9972  containing 

special  flag  and  time  values 
for  diagnosing  invalid  data. 
COMMON/FDSUM/ITIME ,  BKl ,  BK2 ,  BK3 , 
BK4,  SQ1,  SQ2,  SQ3 ,  SQ4 ,  PTl ,  PT2 , 

PT3 ,  PT4 ,  I FOLD,  I FUNK ,  NREAD 
where:  ITIME  *  Forecast  time  period 
required 
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Grid  blocks  required 


BKl 
BK2 
BK3 
BK4 
SQl 

SQ2  Subsquares  required 

SQ3 

SQ4 

PTl 

PT2  Weighting  factors  of 

PT3  subsquare  points 

PT4 

IFOLO  ■  An  error  flag  which  is 
set  if  the  current 
Winds  Aloft  data  are 
too  old, 

I  FUNK  =*  An  error  flag  which  is 
set  if  the  Winds  Aloft 
data  required  are 
missing  or  unknown. 
NREAD  a  Number  of  disk  reads 
required  in  order  to 
compute  the  Winds 
Aloft  results. 

Output: 

SUMT  *  Interpolated  temperature  valve. 

SUMX  »  Interpolated  x  coordinate  of 
the  wind  vector. 

SUMY  »  Interpolated  Y  coordinate  of 
the  wind  vector. 


MQQfJLE  HAMS: 


WTTOR3 


PROGRAM: 

SOURCE  PILE : 
PUROSE: 

CALLING  ROUTINE S: 
CALLING  SEQUENCE: 


COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 


COMMENTS: 


FDRTRV 


WTPOR3 . FTN 


This  subroutine  re-apportions  the  weighting 
factor  of  a  subsquare  point  having  unknown 
wind  data  amongst  the  three  other  points  in 
order  to  complete  interpolation  of  wind 
data  within  this  plane. 

SUMMIT 


call  WTFOR3  (PTlK ,  PT2K,  PT3K ,  PTUNK) 
where:  PTlK  *  weighting  factor  of  point  1 

PT2K  •»  weighting  factor  of  point  2 

PT3K  *  weighting  factor  of  point  3 

PTUNK  »  weighting  factor  of  point 
having  unknown  data  values 


None 


This  subroutine  r e-appor tions  the  weighting 
factor  of  a  subsquare  point  having  unknown 
wind  data  amongst  the  three  other  points  in 
order  to  complete  interpolation  of  wind 
data  within  this  plane. 

Input: 

PTlK  »  Weighting  factor  of  point  1. 

PT2K  »  Weighting  factor  of  point  2. 

PT3K  »  weighting  factor  of  point  3. 

PTUNK  *  Weighting  factor  of  point 

having  unknown  data  values. 

Output: 


PTlK  »  New  weighting  factor  of  point  1. 
PT2K  «  New  weighting  factor  of  point  2. 
PT3K  *  New  weighting  factor  of  point  3. 
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PDP-11/70®  DDPPRG 


MODULE  NAME: 

PROGRAM: 

SOURCE  FILE: 

PURPOSE: 

CALLING  ROUTINES: 

CALLING  SEQUENCE: 
COMMON: 

SUBROUTINES  CALLED: 

FUNCTION  DESCRIPTION: 


COMMENTS: 


UDFPRG 
UDFPRG 
UDFPRG. FTN 

To  create  the  VRS  report  data  file  OOP. DAT 

Run  by  user  to  re-create  the  Universal  Data 
Pile 

None 


NOMESG ,  GETADR,  WTQIO,  I DATE,  TIME,  GETLUN, 
ACTIV,  DICT 


This  program  creates  the  universal  Data 
File  (fJDF)  and  stores  the  message,  "Report 
Not  Available"  within  each  SA  and  FT  report 
location.  It  also  inserts  the  special 
message,  "Current  Report  Not  Available, 
Previous  Valid  Report  Is...."  for  locid 
'S00'.  This  is  a  special  locid  used  by  VRS 
Retrieval. 


Input: 

COMMON/VRSGL8/MAP  (10240),  PDICIN 
(700),  PDICO  (350),  ATADII  (160), 
ATADIO  (160) 

where:  MAP  »  A  byte  array 

representing  the  status 
of  the  UDF. 

PDICIN  ■»  a  byte  array  containing 
dictionary  input  from 
NOMESG . 


PDICO  •»  An  integer  array 

containing  dictionary 
output  corresponding  to 
PDICIN. 


ATADII  »  A  byte  array  containing 
dictionary  input  from 
FDRTRV. 

ATADIO  *  An  integer  array 

containing  dictionary 
output  corresponding  to 
ATADII. 


Output: 

None 
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MODULE  MAMS: 


NOMESG 


PROGRAM: 

SOURCE  FILS: 
PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE: 


COMMON: 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 


UDFPRG 
NOMESG. PTN 

To  create  a  'report  not  available'  report 
£or  given  location. 

UDFPRG 

Call  NOMESG  (LOC,  SAMESG ,  FTMESG) 

Where:  LOC  «  location  identifier 

SAMESG  *  block  number  of  SA  message 
FTMESG  ■  block  number  of  FT  message 


BLCR8 ,  IOBLCK ,  ACTIV,  DICT 


This  subroutine,  called  by  UDFPRG,  creates 
the  message  "Report  Not  Available"  for  each 
SA  and  FT  report  locid  and  the  message 
"Current  Report  Not  Available,  Previous 
Valid  Report  Is..."  for  locid  '$00'.  It 
returns  the  block  number  where  each  message 
is  stored  to  UDFPRG  for  insertion  into  the 
Locator  Index  Table. 

Input: 

LOC  *  Location  identifier. 

COMMON/VRSGLB/MAP  (10240),  PDICTN 

(700),  PD I CO  (350),  ATADII  (160), 

ATADIO  (160) 

where:  MAP  «  A  byte  array 

representing  the  status 
of  the  UDF. 

PDICIN  »  A  byte  array  containing 
dictionary  input  from 
NOMESG. 

PDICO  »  An  integer  array 

containing  dictionary 
output  corresponding  to 
PDICIN. 

ATADII  *  A  byte  array  containing 
dictionary  input  from 
FDRTRV. 

ATADIO  *  An  integer  array 

containing  dictionary 
output  corresponding  to 
ATADII. 

COMMON/UBLOCK/UDFBLK 

where:  UDFBLK  ■  Number  of  Last  UDF 
block  written. 

Output: 

SAMESG  *  Slock  number  of  SA  message 

FTMESG  »  Block  number  of  FT  message 


COMMENTS: 
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MODULE  NAME: 


VRINIT 


PROGRAM: 

SOURCE  PILE: 

PURPOSE: 

CALLING  ROUTINES: 
CALLING  SEQUENCE; 
COMMON; 

SUBROUTINES  CALLED: 
FUNCTION  DESCRIPTION: 


COMMENTS: 


t 

>■ 

$ 


VRINT 

VRINIT.FTN 

To  initialize  the  VRS  processor  data  base 
map  and  pointers 

Run  by  user  at  start-up  time 

None 


TIME,  VRSMAP ,  VRSPTR 

This  program  clears  and  re-initializes  the 
VRS  data  base  map  based  upon  current  report 
information  within  the  LIT  and  re-sets  the 
history  file  pointers  for  SA's,  ft's  and 
Winds  Aloft  to  their  last  major 
transmission  point  in  the  KCW.DAT  file. 
Input: 

COMMON/VRSGLB/MAP  (10240),  PDICIN 
(700),  PDICO  (350),  ATADII  (160), 

ATADIO  (160)  of  which  only  MAP  is  used. 
MAP  *  A  byte  array  representing  the 
status  of  the  UDF. 

Output: 

None 


MODULE  NAME: 


VRSMAP 


PROGRAM; 

SOURCE  PILE: 

PURPOSE: 

CALLING  ROUTINES; 
CALLING  SEQUENCE; 

COMMON; 

SUBROUTINES  CALLED; 
FUNCTION  DESCRIPTION; 


COMMENTS; 


VRINIT 
VRSMAP .  FTN 

To  initialize  the  VRS  processor  data  base 
map. 

VRINIT 

call  VRSMAP  (MAP) 

where:  MAP  »  10240  byte  map  array  of 

VRS  which  will  be  stored 
in  the  global  common  VRSGLB 


None 

This  subroutine  initializes  the  VRS  global 
common  mao.  The  map  contains  a  byte 
corresponding  to  each  block  in  the  UDP. 

For  ali  pre-allocated  blocks  in  the  UDP, 
i.e.,  the  map,  the  region  table,  the  LIT, 
and  the  Winds  Aloft  data  blocks,  the 
corresponding  bytes  of  the  map  are  3et  to  a 
value  of  one  (1) .  All  other  bytes  are 
initialized  to  -1  to  indicate  that  the 
blocks  are  free.  The  subroutine  then  scans 
the  Locator  Index  Table  (LIT)  and  sets  the 
bytes  for  each  block  containing  a  report, 
including  blocks  chained  for  a  report.  If 
there  is  a  discrepancy  for  a  report  block, 
such  as  a  block  number  out  of  range,  then 
all  the  blocks  for  that  locator  index  for 
the  report  are  zeroed. 

Input; 

MAP  -*  A  byte  array  representing  the 
status  of  the  UDF. 

Output: 

MAP  «  A  byte  array  representing  the 
status  of  the  UDF. 
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MODULE  MAMS 


VRSPTR 


PROGRAM; 

SOURCE  PILE; 

PURPOSE: 

CALLING  ROUTINES; 
CALLING  SEQUENCE; 
COMMON; 

SUBROUTINES  CALLED; 
FUNCTION  DESCRIPTION; 

i 


COMMENTS: 


VRINIT 
VRSPTR. FTN 

To  initialize  the  VRS  processor  data  base 
pointers . 

VRINIT 

Call  VRSPTR 


DTELAP,  ZUL.'JTM,  TIME,  GTRPT,  EXTHED,  EXTSTR 

This  subroutine  re-sets  the  history  file 
(SPl.DAT)  pointers  to  the  last  major 
transmission  points  in  KCW.DAT  for  SA's, 
FT's  and  Winds  Aloft.  The  method  used  for 
each  report  type  is  to  back-up  half  a  file 
size  from  the  current  pointer  position  in 
the  KCW.DAT  file  and  sequentially  read 
headers  until  the  calculated  desired 
starting  point  is  found. 

Input: 

None 

Output: 

None 
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APPENDIX  B 


PDP-11/34®  and  PDP- 11/70® 


Line  Communication 


B.l  PDP-11/34  and  PDP-11/70  Communications  Protocol 


During  communications  among  the  VRS  computer,  the 
PDP-11/34,  and  the  Processor  computer  the  PDP-11/70,  errors 
occur  in  transmitting  information  over  the  1200  BAUD 
asynchronous  dedicated  line.  In  order  to  recognize  and 
eliminate  these  errors,  two  validity  checks  are  performed  on 
all  communications.  Appended  to  each  message  from  the  11/70  to 
the  11/34  are  a  check-sum  of  two  digits  followed  by  a  character 
count  of  data  characters  to  be  transmitted.  Before 
transmitting  the  message  to  the  11/34,  Retrieval  sums  the  value 
of  each  character  to  be  transmitted.  The  sixteen  bit  check-sum 
is  added  to  the  transmitted  message,  along  with  an  8-bit  count 
of  the  number  of  characters  to  be  transmitted,  as  each 
character  is  received  by  the  PDP-11/34,  its  sum  is  added  to  the 
value  of  the  previous  characters  received  in  a  particular 
message.  When  the  message  is  complete,  the  check-sum  is 
compared  to  the  check-sum  transmitted  by  the  11/70.  The 
character  count  is  also  compared.  If  both  tests  pass,  the 
11/34  assumes  the  message  is  correct.  If  a  heck  fails,  the 

message  is  dropped  on  the  floor.  The  11/34  line  timeout 

routine  would  then  request  the  information  again  as  the  VRS 
software  on  the  11/34  never  sees  the  errant  message. 

The  same  procedure  is  followed  on  transmissions  by  the 
11/34  to  the  11/70  with  one  difference:  The  terminal  handler 
recognizes  some  character  values  as  special,  which  will 
initiate  action  by  RSX-11D.  As  a  result,  the  check-sura 
characters  transmitted  by  the  11/34  contain  none  of  these 

characters.  Instead,  the  first  ten  bits  of  the  check-sum  are 

divided  into  two  five-bit  fields  and  added  to  octal  40. 
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Likewise,  the  character  count  is  added  to  octal  40.  This 
procedure  insures  that  no  control  characters  are  passed  to  the 
RSX-llD  operating  system. 

In  the  future,  the  software  will  use  a  2400  band 
synchronous  line  using  a  DMC-11  on.  the  PDP-11/34  and  DECNET 
software  on  the  PDP-11/70  .  The  following  sections  describe 
how  that  communication  will  proceed.  When  using  DECNET-DDCMP, 
the  error  checks  now  performed  will  be  deleted  as  redundant. 


PDP-11/34®  — 

PDP-11/70 ®  DECNET  ( DDCMP ) 

Channel  Type 

-  Full  Duplex  Synchronous 

Data  Code 

-  ASCII  and  Transparent  Text 

Line  Speed 

-  2400  Baud 

Error  Controls 

-  CRC-16  Block  Parity.  Block 

• 

ACK/NAK  procedures 

Block  Size 

-  194  characters  (including  framing 

e 

characters).  Last  block  is  variable  in 

length  up  to  194  characters. 

DATA  LINK  CONTROL  CHARACTERS 
(ASCII) 

ENQ  -  00000101  Octal  5  -  Enquiry 

SPH  -  00000001  Octal  1  -  Start  of  Header 

STX  -  00000000  Octal  2  -  Start  of  Text 

ETB  -  00010111  Octal  27  -  End  of  Transmission  Block 

ETX  -  00000011  Octal  3  -  End  of  Text 

SYN  -  00020220  Octal  26  -  Synchronous  Idle 
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ACK  -  00000110  Octal  6  -  Affirmative  Acknowledgment 
NAK  -  00010101  Octal  25  -  Negative  Acknowledgment 
DLE  •  00010000  Octal  20  -  Data-Link  Escape 

The  first  character  (ENQ)  is  an  out-of-block  (not  framed) 
character  while  the  remaining  characters  enable  the  hardware  to 
detect  the  beginning  and  end  of  data  transmission. 

All  data  transmitted  must  be  preceded  by  at  least  three  SYN 
characters. 

Message  Formats 

A.  Data  Messages  (1st  and  intermediate  blocks) 
character  #: 

12345  190  191  192  193  194 

message: 

0  SOH  N  DLE  STX  Transparent  Text  Data  DLE  ETB  BCC 

Data  Messages  (last  block) 
character  #: 

1  2  3  4  5  K  K+l  K+2  K+3  K+4 

message: 

0  SOH  N  DLE  STX  Transparent  Text  Data  DLE  ETX  BCC 

where  K  +  4  »  194 

B.  Acknowledgment  Message 

character  #:  1  2  3  456 

message:  0  SOH  N  ACK/NAK  ETX  BCC 
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C.  Line  Synchronization  Messages 


1 

0  ENQ 

where: 

0  -  Required  number  of  SYN  characters 

SOH  -  Start  of  header  character 

N  -  Block  sequence  number  (0-9) -1  ASCII 

character 

DLE  STX  -  Start  of  Transparent  text  characters 

DLE  ETB  -  End  of  intermediate  transparent  text 
characters 

DLE  ETX  -  End  of  transparent  text  message  characters 

BCC  -  Block  check  characters  (CRC-16; 

2  characters) 

ACK  -  Affirmative  acknowledgment  character 

NAK  -  Negative  acknowledgment  character 

ENQ  -  Enquiry  character 

The  block  check  character  (BCC)  is  used  to  provide  a  block 
data  integrity  check.  It  is  a  cyclic- redundancy  check 
(CRC-16)*  that  uses  an  arithmetic  accumulation  that  is  reset 

♦See  Section  B.6. 
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with  the  SOH  character  in  the  transmission,  and  restarted  with 
the  character  following.  Thereafter,  all  characters  in  the 
transmission  up  to  and  including  the  ETB  or  ETX  character  are 
included  in  the  CRC  calculation.  Within  blocks  of  transparent 
text,  the  first  DLE  character  of  all  two-character  DLE 
sequences  is  excluded  from  the  BCC. 


B.3  Transparent-Text  Mode 

This  mode  permits  greater  versatility  in  the  range  of  coded 
data  that  can  be  transmitted.  This  is  because  all  data, 
including  the  normally  restricted  data-link  line-control 
characters,  are  treated  only  as  specific  bit  patterns  when 
transmitted  in  transparent  mode.  Thus,  unrestricted  coding  of 
data  is  permitted  for  transparent-mode  operation.  This  mode  is 
particularly  useful  for  transmitting  binary  data  and  unique 
specialized  codes. 

Any  data-link  control  characters  transmitted  during 
transparent  mode  and  required  to  be  effective  must  be  preceded 
by  a  DLE.  Thus,  the  following  sequences  are  effective  during 
transparent-mode  operation: 


SEQUENCE  USE 

DLE  STX  Initiates  the  transparent  mode  for  the 

following  block  of  data. 


DLE  ETB  Terminates  a  block  of  transparent  data, 

returns  the  data  link  to  ASCII  mode,  and 
calls  for  a  reply. 
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OLE  ETX  Terminates  the  transparent  data,  returns  the 

data  link  to  ASCII  mode,  and  calls  for  a 
reply. 

OLE  E NQ  Indicates  a  "disregard  this  block  of 

transparent  data"  and  returns  to  ASCII  mode. 

OLE  OLE  Used  when  a  bit  pattern  equivalent  to  OLE 

appears  with  the  transparent  data  to  permit 
transmission  of  the  OLE  as  data. 

All  replies,  inquiries,  and  headers  are  transmitted  in 
ASCII  mode.  Transparent  data  are  received  on  a 
character-by-character  basis;  thus,  character  phase  is 
maintained  in  the  usual  manner. 

NOTE;  ASCII  data  may  also  be  transmitted  in  ASCII  mode  by 
omitting  the  DLE  character  from  the  data  link  control 
sequences  -  DLE  STX,  DLE  ETB,  DLE  ETX,  etc. 

B.4  General  Transmission  procedures 

Each  data  block  transmitted  and  received  will  be 
acknowledged  when  feasible.  The  acknowledgment  may  be  a 
positive  ACK  or  negative  NAK.  A  positive  ACK  is  sent  if  the 
following  conditions  are  met: 

1.  The  block  size  is  correct. 

2.  The  SOH/STX  and  ETB/ETX  characters  are  proper  (valid 
and  expected) . 

3.  The  BCC  is  correct. 

4.  The  block  sequence  number  is  correct. 
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Each  time  a  center  is  forced  into  a  cancel  mode  during  a 
transmission  regardless  of  the  reason,  the  ENQ  procedure  will 
be  initiated  before  the  next  transmission  is  started. 

If  the  center  receives  an  ENQ  after  the  start  of  a  data 
transmission  (on  input)  and  prior  to  an  end  transmission 
character  (ETX)  it  will  treat  the  ENQ  as  a  cancel  transmission 
request  from  the  transmitting  center. 

8.4.1  Output  Timing 

A  center  establishes  a  timeout  value  of  5.9  seconds  for 
every  block  transmitted.  If  the  receiving  center  does  not 
acknowledge  receipt  of  the  block  before  the  timeout  is 
detected,  an  automatic  block  return  procedure  is  invoked.  The 
timeout  value  increases  to  one  minute  for  ETX  blocks  with  the 
same  block  rerun  procedure  when  a  timeout  is  experienced. 

If  any  of  the  above  conditions  are  not  met,  the  center  will 
either  transmit  a  negative  acknowledgment  (NAK)  or  refuse  to 
respond,  forcing  the  transmitting  center  to  rerun  the  block 
when  expected  acknowledgment  is  overdue. 

B.4.2  Block  Acknowledge  Procedures 

A  center  will  transmit  an  ACK  or  NAK  reply  block  for  every 
block  received.  The  data  block  ACK/NAK  format  is  the  same  as 
the  ENQ  response  except  for  the  content  of  the  N  field.  That 
is,  for  data  block  acknowledgment  the  N  field  of  the  reply 
block  contains  the  block  number  being  acknowledged  (ACK  or  NAK) 
whereas,  for  an  ENQ  response,  the  N  field  is  always  ASCII  zero. 
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B.4.3  Block  Rerun  procedures 

Data  blocks  are  retransmitted  every  time  a  center  receives 
an  NAK  acknowledgment  from  the  other  center  or  when  no 
acknowledgment  is  received  within  the  allotted  time 
(S.9  seconds  NON-ETX  blocks;  60  seconds  for.  ETX  blocks).  If  an 
NAK  or  data  timeout  occurs  three  times  for  the  same  data  block, 
the  center  initiates  a  cancel  and  returns  to  the  ENQ 
procedure.  If  a  message  is  retransmitted  three  times  without 
success,  it  is  aborted.  When  a  message  abort  procedures  are 
used,  the  center  will  generate  a  printout  (3NAK)  and  continue 
with  the  next  message  available  for  transmission. 


B.4.4  Block  Transmission  Procedures 

A  center  will  stop  transmitting  when  a  persistent  error 
condition  has  been  detected.  When  a  positive  acknowledgment  is 
received,  the  center  will  resume  transmission. 


B.5  Line  Synchronization  Procedures 

A  center  will  initiate  an  ENQ  procedure  to  determine 
circuit  viability  an  operational  interface  capability  with  the 
other  center.  The  format  for  the  ENQ  transmission  is: 

character  #:  1 

message :  0  ENQ 

where  0  represents  the  required  SYN  character  sequence. 

The  SYN  characters  are  followed  by  a  single  ASCII  ENQ 
character.  The  ENQ  sequence  is  sent  at  one  second  intervals 
until  two  consecutive  positive  replies  are  received.  After  150 
unanswered  ENQ's  have  been  transmitted,  the  center  will 
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generate  a  printout  indicating  a  possible  line  problem  exists. 
The  center  takes  no  other  action  at  this  time  and  continues  to 
ENQ  the  other  center.  (It  should  be  noted  here  that  the  other 
center  has  a  similar  responsibility  regarding  the  transmission 
and  acknowledgment  of  the  ENQ  procedure). 

The  format  for  the  response  to  the  ENQ  block  is: 

character  #:  12  3  4  5,6 

message:  *0  SOH  N  ACK/NAK  ETX  BCC 

All  ENQ  reply  blocks  are  framed  with  SOH  and  ETX  control 
characters.  The  rule  which  governs  BCC  generation  for  data 
blocks  is  also  valid  for  reply  blocks.  The  N  field  is  always 
an  ASCII  zero  when  responding  to  an  ENQ.  If  the  center  is  not 
in  an  operational  mode  that  would  permit  a  large  volume  of  data 
transfers  on  the  circuit,  a  NAK  responds  is  sent  to  the  ENQ. 

The  center  receiving  the  NAK  response  must  withhold  the 
transmission  of  the  next  ENQ  for  thirty  seconds. 

B.6  Cyclic  Redundancy  Checking  (CRC~16) 

Cyclic  Redundancy  Checking  (CRC-16)  is  a  sophisticated 
method  of  block  checking  a  data  stream.  This  type  of  checking 
involves  a  polynomial  division  of  the  data  stream  by  a  CRC 
polynomial.  The  l's  and  0's  of  the  data  become  the 
coefficients  of  the  dividend  polynomial  while  the  CRC 
polynomial  is  present  atX  X  +  dx  +1.  The  division 
uses  subtraction  modulo  2  (no  carries)  and  the  remainder  serves 
as  the  Cyclic  Redundancy  Check.  The  receiving  station  compares 
the  transmitted  remainder  with  its  own  computed  remainder  and 
an  equal  condition  indicates  that  no  error  has  occurred. 
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REPORT  OF  NEW  TECHNOLOGY 


There  have  been  no  inventions  or  important  discoveries  made  during 
the  performance  of  this  contract.  However,  the  Voice  Response  System  ~ 

has  been  implemented  using  a  unique  software  design  on  both  the  PDP-11/34® 
and  the  PDP-11/70  ® 

The  PDP-11/34  software  was  designed  to  run  under  the  single-user 
operating  system  RT-11  and  operationally  to  perform  as  a  multi-user  (20- 
channel)  system.  This  was  accomplished  by  using  the  RT-11  capability  of 
asynchronous  I/O  with  assigned  priority.  The  priority  assignment  for 
each  VRS  I/O  component  was  developed  for  uninterrupted  speech  on  each 
channel. 

Each  channel  follows  a  table-driven  protocol  using  separate  storage 
areas  in  memory  to  maintain  channel  status  after  asynchronous  I/O  com¬ 
pletion.  Improvements  were  made  to  the  system  in  upgrading  VRS  from  10 
to  20  channels  by  taking  advantage  of  the  extended  memory  management  of 
RT-11  to  utilize  the  32K  of  memory  added  to  the  system.  This  involved 
the  allocation  and  access  of  the  speech  buffers  and  dictionary  in  upper 
memory.  See  section  2.2  for  the  software  description. 

A  single-user /20-channel  design  has  been  implemented  for  the  PDP- 
11/70  weather  retrieval  program.  See  section  2.4.4.  It  employs  separate 
storage  areas  for  maintaining  channel-briefing  status  upon  completion  of 
the  asynchronous  I/O.  A  unique  file  system  has  been  designed  for  storage 
and  retrieval  of  the  weather  reports  processed  on  the  PDP-11/ 70.  This 
file  system  allows  multi-task  (processor  and  retrieval  tasks)  access  and 
update  without  conflict.  It  exercises  the  RSX-11  operating  system  feature 
of  shared  global  common  areas  in  memory  for  the  file  block  map  and  for 
multi-task  communications.  This  system  is  described  in  section  2.4. 
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